Introduction refactoring begin

docs/v1/API.en.html

@@ -581,7 +581,7 @@ ul.references li p a.back-anchor {
     <li><a class="share share-facebook" href="https://www.facebook.com/sharer.php?u=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F" target="_blank"> </a></li><li><a class="share share-twitter" href="https://twitter.com/intent/tweet?text=The%20API%20by%20Sergey%20Konstantinov%20%E2%80%94%20a%20book%20about%20designing%20APIs%2C%20extending%20them%20and%20finding%20a%20proper%20place%20in%20the%20market&#x26;url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F&#x26;hashtags=API%2CTheAPIBook&#x26;via=blogovodoved" target="_blank"> </a></li><li><a class="share share-linkedin" href="https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F" target="_blank"> </a></li><li><a class="share share-reddit" href="http://www.reddit.com/submit?url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F&#x26;title=The%20API%20by%20Sergey%20Konstantinov%20%E2%80%94%20a%20book%20about%20designing%20APIs%2C%20extending%20them%20and%20finding%20a%20proper%20place%20in%20the%20market" target="_blank"> </a></li>
         <li class="copy-link">Link: <input type="text" value="https://twirl.github.io/The-API-Book/"><button type="button" class="copy-button"></button></li>
 </ul>
-    <section class="side-toc"><nav><h2 class="toc">Table of Contents</h2><ul class="table-of-contents"><li><a href="#section-1">Introduction</a><ul><li><a href="#intro-structure">Chapter 1. On the Structure of This Book</a></li><li><a href="#intro-api-definition">Chapter 2. The API Definition</a></li><li><a href="#intro-api-quality">Chapter 3. API Quality Criteria</a></li><li><a href="#intro-back-compat">Chapter 4. On Backwards Compatibility</a></li><li><a href="#intro-versioning">Chapter 5. On Versioning</a></li><li><a href="#intro-terms-notation">Chapter 6. Terms and Notation Keys</a></li></ul></li><li><a href="#section-2">Section I. The API Design</a><ul><li><a href="#api-design-context-pyramid">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#api-design-defining-field">Chapter 8. Defining an Application Field</a></li><li><a href="#api-design-separating-abstractions">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#api-design-isolating-responsibility">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#api-design-describing-interfaces">Chapter 11. Describing Final Interfaces</a></li><li><a href="#api-design-annex">Chapter 12. Annex to Section I. Generic API Example</a></li></ul></li><li><a href="#section-3">Section II. The Backwards Compatibility</a><ul><li><a href="#back-compat-statement">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#back-compat-iceberg-waterline">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#back-compat-abstracting-extending">Chapter 15. Extending through Abstracting</a></li><li><a href="#back-compat-strong-coupling">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#back-compat-weak-coupling">Chapter 17. Weak Coupling</a></li><li><a href="#back-compat-universal-interfaces">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#back-compat-serenity-notepad">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#api-product">Chapter 20. API as a Product</a></li><li><a href="#api-product-business-models">Chapter 21. The API Business Models</a></li><li><a href="#api-product-vision">Chapter 22. Developing a Product Vision</a></li><li><a href="#api-product-devrel">Chapter 23. Communicating with Developers</a></li><li><a href="#api-product-business-comms">Chapter 24. Communicating with Business Owners</a></li><li><a href="#api-product-range">Chapter 25. The API Services Range</a></li><li><a href="#api-product-kpi">Chapter 26. The API Key Performance Indicators</a></li><li><a href="#api-product-antifraud">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#api-product-tos-violations">Chapter 28. The Technical Means of Preventing ToS Violations</a></li><li><a href="#api-product-customer-support">Chapter 29. Supporting customers</a></li><li><a href="#api-product-documentation">Chapter 30. The Documentation</a></li><li><a href="#api-product-testing">Chapter 31. The Testing Environment</a></li><li><a href="#api-product-expectations">Chapter 32. Managing expectations</a></li></ul></li></ul></nav><div style="page-break-after: always;"></div></section>
+    <section class="side-toc"><nav><h2 class="toc">Table of Contents</h2><ul class="table-of-contents"><li><a href="#section-1">Introduction</a><ul><li><a href="#intro-structure">Chapter 1. On the Structure of This Book</a></li><li><a href="#intro-api-definition">Chapter 2. The API Definition</a></li><li><a href="#intro-api-quality">Chapter 3. API Quality Criteria</a></li><li><a href="#intro-back-compat">Chapter 4. On Backwards Compatibility</a></li><li><a href="#intro-versioning">Chapter 5. On Versioning</a></li><li><a href="#intro-terms-notation">Chapter 6. Terms and Notation Keys</a></li></ul></li><li><a href="#section-2">Section I. The API Design</a><ul><li><a href="#api-design-context-pyramid">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#api-design-defining-field">Chapter 8. Defining an Application Field</a></li><li><a href="#api-design-separating-abstractions">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#api-design-isolating-responsibility">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#api-design-describing-interfaces">Chapter 11. Describing Final Interfaces</a></li><li><a href="#api-design-annex">Chapter 12. Annex to Section I. Generic API Example</a></li></ul></li><li><a href="#section-3">Section II. The Backwards Compatibility</a><ul><li><a href="#back-compat-statement">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#back-compat-iceberg-waterline">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#back-compat-abstracting-extending">Chapter 15. Extending through Abstracting</a></li><li><a href="#back-compat-strong-coupling">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#back-compat-weak-coupling">Chapter 17. Weak Coupling</a></li><li><a href="#back-compat-universal-interfaces">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#back-compat-serenity-notepad">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#api-product">Chapter 20. API as a Product</a></li><li><a href="#api-product-business-models">Chapter 21. The API Business Models</a></li><li><a href="#api-product-vision">Chapter 22. Developing a Product Vision</a></li><li><a href="#api-product-devrel">Chapter 23. Communicating with Developers</a></li><li><a href="#api-product-business-comms">Chapter 24. Communicating with Business Owners</a></li><li><a href="#api-product-range">Chapter 25. The API Services Range</a></li><li><a href="#api-product-kpi">Chapter 26. The API Key Performance Indicators</a></li><li><a href="#api-product-antifraud">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#api-product-tos-violations">Chapter 28. The Technical Means of Preventing ToS Violations</a></li><li><a href="#api-product-customer-support">Chapter 29. Supporting customers</a></li><li><a href="#api-product-documentation">Chapter 30. The Documentation</a></li><li><a href="#api-product-testing">Chapter 31. The Testing Environment</a></li><li><a href="#api-product-expectations">Chapter 32. Managing Expectations</a></li></ul></li></ul></nav><div style="page-break-after: always;"></div></section>
     <button type="button" class="close"></button></aside><article>
 <div class="cover">
     <h1>
@@ -596,7 +596,7 @@ ul.references li p a.back-anchor {
 <img class="cc-by-nc-img" alt="Creative Commons «Attribution-NonCommercial» Logo" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFgAAAAfCAMAAABUFvrSAAAAIGNIUk0AAHolAACAgwAA+f8AAIDpAAB1MAAA6mAAADqYAAAXb5JfxUYAAAAEZ0FNQQAAsY58+1GTAAAAAXNSR0IB2cksfwAAAblQTFRF////////////////8fHx7+/v4+Pj39/f1tXV09bS0tXS0tXR0dTR0dTQ0NTQ0NPPz9PPztLOztHNzdHNzdHMz8/PzdDMzNDMzNDLzM/Ly8/Ly8/Ky87Kys3Jyc3Jyc3IyMzIyMzHx8vHxsrGxsrFxcnFyMfHxcnExMnExMjDw8jDxMfDw8fCwsfCwcXAwMXAwMW/wMS/v8S+v8O+vsO+vsK9vcK9vcK8v7+/vMG8vMG7vMC8u8C7u8C6ur+6ur+5ub65ub64uL23t7y2urm5tru1tbq0tLqztLmzs7iysrixsrexsbewsbawsLavsLWvr7Wur7SusLOvrrStrrOtr7KvrbOsrLKrr6+vq7GqrKurn6OenqCdn5+fnp2dmpiZlpmWk5iTkZSRkZORkY+Pj4+PiYyJjIqLh4aHhIaEhIWEgoWChIGCgICAfX98fH98fnt8eXx5eHV2dnN0dXJzcHJvcHBwaGVmYGBgXV5dWldYUFFQUFBQQ0RDQEBAPj8+Pzs8NTY1MjMxMjExMDAwMS0uKSkpKCkoKCUmIx8gICAgHxscGxsbGRkZEBAQDg4ODQ4NDQwNAAAABjFVaAAAAAN0Uk5TAAoO5yEBUwAAA5NJREFUeNq1lo930lYUx7NdaUprjKZzQIlFHJtSGVarg+E6Slmx2OpwOihqt1mqm27oGJNh+VG3pbCwGvH7F+8kAUpC6Jl4+g4575xveJ933/e+d1+Y93EojWGARDwWuRyc9XlnRJfD4XKf8vr8wfnIYjyRXPv6djqdyb59Axgk4tHQxYDP4xZ4bsJunzjKC9MeX2AuFFXJqdvpzEhkBvFo6IL/jChwT2ptdRHt2mPuhNt7LvhZNJ64fjN1pxtyoaG+bhTMDEsdDGKhC36vk8/t7Ru0t8k7PGeDocX4yurNTsgPmkC9VKoDzQf9hCE6GEQu+r0OrgJAKefD4XxZAVA5/4Hn3Fwktpxc00O+9xpVloiIreJ1H2GYDgaXA2ecKlfJ20hvGwrQPO/wBuYXlhJayNlsE2UiAtTXaO4DdH1r26yDQdAn8hVAYqnXbBJQ4d2+YCi2nLxxK53JFFAd74Kpip6fBfz9PdHWqzfFMYOugmdPCzlAshEZyZsnPP5LC/Frq6k7mUwDffOyaHTHN/CP/PIP5H/CXYOugn1ubg/KSTI0m4I9btoX/DyWuK56gbqqlqEtnOroja///pssy8WxcaOugr1TT4A8mdoG8FjwBq5El5M3VHCJNCd0L0r74BLRJ0UAxXGDroJnjteg2IjC1Xo9r3cPiUhBjT+lerGydutgMNFYcVeWt78ygUWurS4wrO3g+rrWldVlt4+6z859sXRtLXWQFUR05Dsal2VZfmm0wjUJPCSS0GLDrQ0JErve2tC8mHD5gpGlxGoq3U2eHrAheSzRtry7i+LdX/81Js9pB8LqmLw+tGN3GLA7PuqCC6iS9XarEo398urN1pGB7fa/wP0HpDR4QH7cNusGK2wnW3kJktqZrRjlSHeS18laL3kltDmxl7xs9l4TkMolyVyEhujadqtAod52W69rHbVQ42f8l77Ut9soZdM7ldO8sDogn15ZXE7qVejtC/3H2pFmDz7So4BnTwv3rYpQTvDMzi/EV7QiNAoYz0T+BSD1lSFWK5viz+90TQN47jrWX+hteQX4k3M+w7uC8dRx7IXpauI+/MH0T/18QH/6df0hsgDjqYu/33+Z5ninmQvq/Ghgwo5KFmA8FwUu173+NzlBHPShWzYHJySL6bpg/PWte+o4N2m3T3K8MP3NzqBp1kZ0bRgWMYCdR1dFl9PpEq8+2rHKxvCID/D4ML4K3zsk7n9pO/RNngRtJQAAAABJRU5ErkJggg==">
 <p class="cc-by-nc">This book is distributed under the <a href="http://creativecommons.org/licenses/by-nc/4.0/">Creative Commons Attribution-NonCommercial 4.0 International licence</a>.</p>
     <p class="text-align-left">Source code available at <a target="_blank" href="https://github.com/twirl/The-API-Book">github.com/twirl/The-API-Book</a></p>
-    </div><p class="share text-align-left">Share: <a class="share share-facebook" href="https://www.facebook.com/sharer.php?u=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F" target="_blank">facebook</a> · <a class="share share-twitter" href="https://twitter.com/intent/tweet?text=The%20API%20by%20Sergey%20Konstantinov%20%E2%80%94%20a%20book%20about%20designing%20APIs%2C%20extending%20them%20and%20finding%20a%20proper%20place%20in%20the%20market&#x26;url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F&#x26;hashtags=API%2CTheAPIBook&#x26;via=blogovodoved" target="_blank">twitter</a> · <a class="share share-linkedin" href="https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F" target="_blank">linkedin</a> · <a class="share share-reddit" href="http://www.reddit.com/submit?url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F&#x26;title=The%20API%20by%20Sergey%20Konstantinov%20%E2%80%94%20a%20book%20about%20designing%20APIs%2C%20extending%20them%20and%20finding%20a%20proper%20place%20in%20the%20market" target="_blank">reddit</a></p><div class="page-break"></div><nav><h2 class="toc">Table of Contents</h2><ul class="table-of-contents"><li><a href="#section-1">Introduction</a><ul><li><a href="#intro-structure">Chapter 1. On the Structure of This Book</a></li><li><a href="#intro-api-definition">Chapter 2. The API Definition</a></li><li><a href="#intro-api-quality">Chapter 3. API Quality Criteria</a></li><li><a href="#intro-back-compat">Chapter 4. On Backwards Compatibility</a></li><li><a href="#intro-versioning">Chapter 5. On Versioning</a></li><li><a href="#intro-terms-notation">Chapter 6. Terms and Notation Keys</a></li></ul></li><li><a href="#section-2">Section I. The API Design</a><ul><li><a href="#api-design-context-pyramid">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#api-design-defining-field">Chapter 8. Defining an Application Field</a></li><li><a href="#api-design-separating-abstractions">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#api-design-isolating-responsibility">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#api-design-describing-interfaces">Chapter 11. Describing Final Interfaces</a></li><li><a href="#api-design-annex">Chapter 12. Annex to Section I. Generic API Example</a></li></ul></li><li><a href="#section-3">Section II. The Backwards Compatibility</a><ul><li><a href="#back-compat-statement">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#back-compat-iceberg-waterline">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#back-compat-abstracting-extending">Chapter 15. Extending through Abstracting</a></li><li><a href="#back-compat-strong-coupling">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#back-compat-weak-coupling">Chapter 17. Weak Coupling</a></li><li><a href="#back-compat-universal-interfaces">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#back-compat-serenity-notepad">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#api-product">Chapter 20. API as a Product</a></li><li><a href="#api-product-business-models">Chapter 21. The API Business Models</a></li><li><a href="#api-product-vision">Chapter 22. Developing a Product Vision</a></li><li><a href="#api-product-devrel">Chapter 23. Communicating with Developers</a></li><li><a href="#api-product-business-comms">Chapter 24. Communicating with Business Owners</a></li><li><a href="#api-product-range">Chapter 25. The API Services Range</a></li><li><a href="#api-product-kpi">Chapter 26. The API Key Performance Indicators</a></li><li><a href="#api-product-antifraud">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#api-product-tos-violations">Chapter 28. The Technical Means of Preventing ToS Violations</a></li><li><a href="#api-product-customer-support">Chapter 29. Supporting customers</a></li><li><a href="#api-product-documentation">Chapter 30. The Documentation</a></li><li><a href="#api-product-testing">Chapter 31. The Testing Environment</a></li><li><a href="#api-product-expectations">Chapter 32. Managing expectations</a></li></ul></li></ul></nav><div style="page-break-after: always;"></div><section class="main-content">
+    </div><p class="share text-align-left">Share: <a class="share share-facebook" href="https://www.facebook.com/sharer.php?u=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F" target="_blank">facebook</a> · <a class="share share-twitter" href="https://twitter.com/intent/tweet?text=The%20API%20by%20Sergey%20Konstantinov%20%E2%80%94%20a%20book%20about%20designing%20APIs%2C%20extending%20them%20and%20finding%20a%20proper%20place%20in%20the%20market&#x26;url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F&#x26;hashtags=API%2CTheAPIBook&#x26;via=blogovodoved" target="_blank">twitter</a> · <a class="share share-linkedin" href="https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F" target="_blank">linkedin</a> · <a class="share share-reddit" href="http://www.reddit.com/submit?url=https%3A%2F%2Ftwirl.github.io%2FThe-API-Book%2F&#x26;title=The%20API%20by%20Sergey%20Konstantinov%20%E2%80%94%20a%20book%20about%20designing%20APIs%2C%20extending%20them%20and%20finding%20a%20proper%20place%20in%20the%20market" target="_blank">reddit</a></p><div class="page-break"></div><nav><h2 class="toc">Table of Contents</h2><ul class="table-of-contents"><li><a href="#section-1">Introduction</a><ul><li><a href="#intro-structure">Chapter 1. On the Structure of This Book</a></li><li><a href="#intro-api-definition">Chapter 2. The API Definition</a></li><li><a href="#intro-api-quality">Chapter 3. API Quality Criteria</a></li><li><a href="#intro-back-compat">Chapter 4. On Backwards Compatibility</a></li><li><a href="#intro-versioning">Chapter 5. On Versioning</a></li><li><a href="#intro-terms-notation">Chapter 6. Terms and Notation Keys</a></li></ul></li><li><a href="#section-2">Section I. The API Design</a><ul><li><a href="#api-design-context-pyramid">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#api-design-defining-field">Chapter 8. Defining an Application Field</a></li><li><a href="#api-design-separating-abstractions">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#api-design-isolating-responsibility">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#api-design-describing-interfaces">Chapter 11. Describing Final Interfaces</a></li><li><a href="#api-design-annex">Chapter 12. Annex to Section I. Generic API Example</a></li></ul></li><li><a href="#section-3">Section II. The Backwards Compatibility</a><ul><li><a href="#back-compat-statement">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#back-compat-iceberg-waterline">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#back-compat-abstracting-extending">Chapter 15. Extending through Abstracting</a></li><li><a href="#back-compat-strong-coupling">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#back-compat-weak-coupling">Chapter 17. Weak Coupling</a></li><li><a href="#back-compat-universal-interfaces">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#back-compat-serenity-notepad">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#api-product">Chapter 20. API as a Product</a></li><li><a href="#api-product-business-models">Chapter 21. The API Business Models</a></li><li><a href="#api-product-vision">Chapter 22. Developing a Product Vision</a></li><li><a href="#api-product-devrel">Chapter 23. Communicating with Developers</a></li><li><a href="#api-product-business-comms">Chapter 24. Communicating with Business Owners</a></li><li><a href="#api-product-range">Chapter 25. The API Services Range</a></li><li><a href="#api-product-kpi">Chapter 26. The API Key Performance Indicators</a></li><li><a href="#api-product-antifraud">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#api-product-tos-violations">Chapter 28. The Technical Means of Preventing ToS Violations</a></li><li><a href="#api-product-customer-support">Chapter 29. Supporting customers</a></li><li><a href="#api-product-documentation">Chapter 30. The Documentation</a></li><li><a href="#api-product-testing">Chapter 31. The Testing Environment</a></li><li><a href="#api-product-expectations">Chapter 32. Managing Expectations</a></li></ul></li></ul></nav><div style="page-break-after: always;"></div><section class="main-content">
 <nav class="page-main"><ul class="nav-folded">
     <li class="share"></li>
     <li class="para">§</li>
@@ -3974,7 +3974,7 @@ ProgramContext.dispatch = (action) => {
 <p>The main disadvantage is the necessity to create a separate scenario for each unhappy path (effectively, for every possible error), and give developers the capability of denoting which scenario they want to run. (For example, like that: if there is a pre-agreed comment to the order, the system will simulate a specific error, and developers will be able to write and debug the code that deals with the error.)</p>
 <h4>The Automation of Testing</h4>
 <p>Your final goal in implementing testing APIs, regardless of which option you choose, is allowing partners to automate the QA process for their products. The testing environment should be developed with this purpose in mind; for example, if an end user might be brought to a 3-D Secure page to pay for the order, the testing environment API must provide some way of simulating the successful (or not) passing of this step. Also, in both variants, it's possible (and desirable) to allow running the scenarios in a fast-forward manner that will allow making auto-testing much faster than manual testing.</p>
-<p>Of course, not every partner will be able to employ this possibility (which also means that a “manual” way of testing usage scenarios must always be supported alongside the programmatical one) simply because not every business might afford to hire a QA automation engineer. Nevertheless, the ability to write such auto-tests is your API's huge competitive advantage from a technically advanced partner's point of view.</p><div class="page-break"></div><h3><a href="#api-product-expectations" class="anchor" id="api-product-expectations">Chapter 32. Managing expectations</a><a href="#chapter-32" class="secondary-anchor" id="chapter-32"> </a></h3>
+<p>Of course, not every partner will be able to employ this possibility (which also means that a “manual” way of testing usage scenarios must always be supported alongside the programmatical one) simply because not every business might afford to hire a QA automation engineer. Nevertheless, the ability to write such auto-tests is your API's huge competitive advantage from a technically advanced partner's point of view.</p><div class="page-break"></div><h3><a href="#api-product-expectations" class="anchor" id="api-product-expectations">Chapter 32. Managing Expectations</a><a href="#chapter-32" class="secondary-anchor" id="chapter-32"> </a></h3>
 <p>Finally, the last aspect we would like to shed the light on is managing partners' expectations regarding the further development of the API. If we talk about consumer qualities, APIs differ little from other B2B software products: in both cases, you need to form some understanding of SLA conditions, available features, interface responsiveness and other characteristics that are important for clients. Still, APIs have their specificities</p>
 <h4>Versioning and Application Lifecycle</h4>
 <p>Ideally, the API once published should live eternally; but as we all are reasonable people, we do understand it's impossible in the real life. Even if we continue supporting older versions, they will still become outdated eventually, and partners will need to rewrite the code to use newer functionality.</p>