fresh build

docs/API.en.html

@@ -576,7 +576,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="#chapter-1">Chapter 1. On the Structure of This Book</a></li><li><a href="#chapter-2">Chapter 2. The API Definition</a></li><li><a href="#chapter-3">Chapter 3. API Quality Criteria</a></li><li><a href="#chapter-4">Chapter 4. Backwards Compatibility</a></li><li><a href="#chapter-5">Chapter 5. On Versioning</a></li><li><a href="#chapter-6">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="#chapter-7">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#chapter-8">Chapter 8. Defining an Application Field</a></li><li><a href="#chapter-9">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#chapter-10">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#chapter-11">Chapter 11. Describing Final Interfaces</a></li><li><a href="#chapter-12">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="#chapter-13">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#chapter-14">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#chapter-15">Chapter 15. Extending through Abstracting</a></li><li><a href="#chapter-16">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#chapter-17">Chapter 17. Weak Coupling</a></li><li><a href="#chapter-18">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#chapter-19">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#chapter-20">Chapter 20. API as a Product</a></li><li><a href="#chapter-21">Chapter 21. API Business Models</a></li><li><a href="#chapter-22">Chapter 22. Developing a Product Vision</a></li><li><a href="#chapter-23">Chapter 23. Communicating with Developers</a></li><li><a href="#chapter-24">Chapter 24. Communicating with Business Owners</a></li><li><a href="#chapter-25">Chapter 25. API Services Range</a></li><li><a href="#chapter-26">Chapter 26. API Key Performance Indicators</a></li><li><a href="#chapter-27">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#chapter-28">Chapter 28. Technical Means of Preventing ToS Violations</a></li><li><a href="#chapter-29">Chapter 29. Supporting customers</a></li><li><a href="#chapter-30">Chapter 30. The Documentation</a></li><li><a href="#chapter-31">Chapter 31. The Testing Environment</a></li><li><a href="#chapter-32">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="#chapter-1">Chapter 1. On the Structure of This Book</a></li><li><a href="#chapter-2">Chapter 2. The API Definition</a></li><li><a href="#chapter-3">Chapter 3. API Quality Criteria</a></li><li><a href="#chapter-4">Chapter 4. Backwards Compatibility</a></li><li><a href="#chapter-5">Chapter 5. On Versioning</a></li><li><a href="#chapter-6">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="#chapter-7">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#chapter-8">Chapter 8. Defining an Application Field</a></li><li><a href="#chapter-9">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#chapter-10">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#chapter-11">Chapter 11. Describing Final Interfaces</a></li><li><a href="#chapter-12">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="#chapter-13">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#chapter-14">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#chapter-15">Chapter 15. Extending through Abstracting</a></li><li><a href="#chapter-16">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#chapter-17">Chapter 17. Weak Coupling</a></li><li><a href="#chapter-18">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#chapter-19">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#chapter-20">Chapter 20. API as a Product</a></li><li><a href="#chapter-21">Chapter 21. The API Business Models</a></li><li><a href="#chapter-22">Chapter 22. Developing a Product Vision</a></li><li><a href="#chapter-23">Chapter 23. Communicating with Developers</a></li><li><a href="#chapter-24">Chapter 24. Communicating with Business Owners</a></li><li><a href="#chapter-25">Chapter 25. The API Services Range</a></li><li><a href="#chapter-26">Chapter 26. The API Key Performance Indicators</a></li><li><a href="#chapter-27">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#chapter-28">Chapter 28. The Technical Means of Preventing ToS Violations</a></li><li><a href="#chapter-29">Chapter 29. Supporting customers</a></li><li><a href="#chapter-30">Chapter 30. The Documentation</a></li><li><a href="#chapter-31">Chapter 31. The Testing Environment</a></li><li><a href="#chapter-32">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>
@@ -591,8 +591,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="#chapter-1">Chapter 1. On the Structure of This Book</a></li><li><a href="#chapter-2">Chapter 2. The API Definition</a></li><li><a href="#chapter-3">Chapter 3. API Quality Criteria</a></li><li><a href="#chapter-4">Chapter 4. Backwards Compatibility</a></li><li><a href="#chapter-5">Chapter 5. On Versioning</a></li><li><a href="#chapter-6">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="#chapter-7">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#chapter-8">Chapter 8. Defining an Application Field</a></li><li><a href="#chapter-9">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#chapter-10">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#chapter-11">Chapter 11. Describing Final Interfaces</a></li><li><a href="#chapter-12">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="#chapter-13">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#chapter-14">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#chapter-15">Chapter 15. Extending through Abstracting</a></li><li><a href="#chapter-16">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#chapter-17">Chapter 17. Weak Coupling</a></li><li><a href="#chapter-18">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#chapter-19">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#chapter-20">Chapter 20. API as a Product</a></li><li><a href="#chapter-21">Chapter 21. API Business Models</a></li><li><a href="#chapter-22">Chapter 22. Developing a Product Vision</a></li><li><a href="#chapter-23">Chapter 23. Communicating with Developers</a></li><li><a href="#chapter-24">Chapter 24. Communicating with Business Owners</a></li><li><a href="#chapter-25">Chapter 25. API Services Range</a></li><li><a href="#chapter-26">Chapter 26. API Key Performance Indicators</a></li><li><a href="#chapter-27">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#chapter-28">Chapter 28. Technical Means of Preventing ToS Violations</a></li><li><a href="#chapter-29">Chapter 29. Supporting customers</a></li><li><a href="#chapter-30">Chapter 30. The Documentation</a></li><li><a href="#chapter-31">Chapter 31. The Testing Environment</a></li><li><a href="#chapter-32">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="#chapter-1">Chapter 1. On the Structure of This Book</a></li><li><a href="#chapter-2">Chapter 2. The API Definition</a></li><li><a href="#chapter-3">Chapter 3. API Quality Criteria</a></li><li><a href="#chapter-4">Chapter 4. Backwards Compatibility</a></li><li><a href="#chapter-5">Chapter 5. On Versioning</a></li><li><a href="#chapter-6">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="#chapter-7">Chapter 7. The API Contexts Pyramid</a></li><li><a href="#chapter-8">Chapter 8. Defining an Application Field</a></li><li><a href="#chapter-9">Chapter 9. Separating Abstraction Levels</a></li><li><a href="#chapter-10">Chapter 10. Isolating Responsibility Areas</a></li><li><a href="#chapter-11">Chapter 11. Describing Final Interfaces</a></li><li><a href="#chapter-12">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="#chapter-13">Chapter 13. The Backwards Compatibility Problem Statement</a></li><li><a href="#chapter-14">Chapter 14. On the Waterline of the Iceberg</a></li><li><a href="#chapter-15">Chapter 15. Extending through Abstracting</a></li><li><a href="#chapter-16">Chapter 16. Strong Coupling and Related Problems</a></li><li><a href="#chapter-17">Chapter 17. Weak Coupling</a></li><li><a href="#chapter-18">Chapter 18. Interfaces as a Universal Pattern</a></li><li><a href="#chapter-19">Chapter 19. The Serenity Notepad</a></li></ul></li><li><a href="#section-4">Section III. The API Product</a><ul><li><a href="#chapter-20">Chapter 20. API as a Product</a></li><li><a href="#chapter-21">Chapter 21. The API Business Models</a></li><li><a href="#chapter-22">Chapter 22. Developing a Product Vision</a></li><li><a href="#chapter-23">Chapter 23. Communicating with Developers</a></li><li><a href="#chapter-24">Chapter 24. Communicating with Business Owners</a></li><li><a href="#chapter-25">Chapter 25. The API Services Range</a></li><li><a href="#chapter-26">Chapter 26. The API Key Performance Indicators</a></li><li><a href="#chapter-27">Chapter 27. Identifying Users and Preventing Fraud</a></li><li><a href="#chapter-28">Chapter 28. The Technical Means of Preventing ToS Violations</a></li><li><a href="#chapter-29">Chapter 29. Supporting customers</a></li><li><a href="#chapter-30">Chapter 30. The Documentation</a></li><li><a href="#chapter-31">Chapter 31. The Testing Environment</a></li><li><a href="#chapter-32">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>
@@ -3130,7 +3129,7 @@ ProgramContext.dispatch = (action) => {
 </ul>
 <p>So it turns out that customers are at the apex of the pyramid: it is customers you need to convince they need not <em>any</em> cup of coffee, but a cup of coffee brewed using our API (interesting question: how will we convey the knowledge which API works under the hood, and why customers should pay their money for it!); then business owners will set the task to integrate the API, and developers will have no other choice but to implement it (which, by the way, means that investing into API's readability and consistency is not <em>that</em> important).</p>
 <p>The truth, of course, lies somewhere in between. In some markets and subject areas, it is developers who make decisions (i.e. which framework to choose); in other markets and areas, it might be business owners or customers. It also depends on the competitiveness of the market: introducing a new frontend framework does not meet any resistance while developing, let's say, a new mobile operating system requires million-dollar investments into promotions and strategic partnerships.</p>
-<p>Here and after, we will describe some ‘averaged’ situations, meaning that all three pyramid levels are important: customers choosing the product which fits their needs best, business owners seeking quality guarantees and lower development costs, as well as software engineers caring about the API capabilities and the convenience of working with it.</p><div class="page-break"></div><h3><a href="#chapter-21" class="anchor" id="chapter-21">Chapter 21. API Business Models</a></h3>
+<p>Here and after, we will describe some ‘averaged’ situations, meaning that all three pyramid levels are important: customers choosing the product which fits their needs best, business owners seeking quality guarantees and lower development costs, as well as software engineers caring about the API capabilities and the convenience of working with it.</p><div class="page-break"></div><h3><a href="#chapter-21" class="anchor" id="chapter-21">Chapter 21. The API Business Models</a></h3>
 <p>Before we proceed to the API product management principles description, let us draw your attention to the issue of profits that companies providing APIs might extract from it. As we will demonstrate in the next chapters, this issue directly affects making product decisions and setting KPIs for the API team. [In brackets, we will provide examples of such models applicable to our coffee-machine API study.]</p>
 <h4>Developers = end users</h4>
 <p>The easiest and the most understandable case is that of providing a service for developers, with no end users involved. First of all, we talk about different software engineering tools: APIs of programming languages, frameworks, operating systems, UI libraries, game engines, etc; in other words, general-purpose interfaces. [In our coffee API case, it means the following: we've developed a library for ordering a cup of coffee, possibly furnished with UI components, and now selling it to coffeeshop chains owners whoever willing to buy it to ease the development of their own applications.] In this case, the answer to the ‘why have an API’ question is self-evident.</p>
@@ -3306,7 +3305,7 @@ ProgramContext.dispatch = (action) => {
 </ul>
 <p>After all, working with business auditory essentially means lucidly explaining the characteristics and the advantages of the product. In that sense, API ‘sells’ just like any other kind of software.</p>
 <p>As a rule, the farther some industry sector is from information technologies, the more enthusiastic its representatives are about your API features, and the less the chance is that this enthusiasm will be converted into a real integration. The one thing that should help the case is extensive work with the community (see the corresponding chapter) that will result in establishing a circle of freelances and outsourcers eager to help non-IT businesses with integrations. You might help develop this market by the creation of educational courses and issuing certificates proving the bearer's skills of working with your API (or some broader layer of technology).</p>
-<p>Market research and getting feedback from business owners work similarly. Those businesses that are far from IT usually can't formulate their demands, so you should be rather creative (and critical-minded) while analyzing the gathered data.</p><div class="page-break"></div><h3><a href="#chapter-25" class="anchor" id="chapter-25">Chapter 25. API Services Range</a></h3>
+<p>Market research and getting feedback from business owners work similarly. Those businesses that are far from IT usually can't formulate their demands, so you should be rather creative (and critical-minded) while analyzing the gathered data.</p><div class="page-break"></div><h3><a href="#chapter-25" class="anchor" id="chapter-25">Chapter 25. The API Services Range</a></h3>
 <p>The important rule of API product management that any major API provider will soon learn formulates like that: there is no sense to ship one specific API; there is always a room for a range of products, and this range is two-dimensional.</p>
 <h4>Horizontal scaling of API services</h4>
 <p>Usually, any functionality available through an API might be split into independent units. For example, in our coffee API, there are offer search endpoints and order processing endpoints. Nothing could prevent us from either pronouncing those functional clusters different APIs or, vice versa, considering them as parts of one API.</p>
@@ -3343,7 +3342,7 @@ ProgramContext.dispatch = (action) => {
 <li>Finally, ready-to-use components and widgets are under your full control, and you might experiment with functionality exposed through them in partners' applications just like if it was your own service. (However, it doesn't automatically mean that you might draw some profits from having this control; for example, if you're allowing inserting pictures by their direct URL, your control over this integration is rather negligible, so it's generally better to provide those kinds of integration that allow having more control over the functionality in partners' apps.)</li>
 </ol>
 <p><strong>NB</strong>. While developing a ‘vertical’ range of APIs, following the principles stated in the <a href="#chapter-14">Chapter 14 ‘On the Iceberg's Waterline’</a> is crucial. You might manipulate widget content and behavior if, and only if, developers can't ‘escape the sandbox’, e.g. have direct access to low-level objects encapsulated within the widget.</p>
-<p>In general, you should aim to have each partner service using the API service that maximizes your profit as an API vendor. Where the partner doesn't try to make some unique experience and needs just a typical solution, you would benefit from making them use widgets, which are under your full control and thus ease the API version fragmentation problem and allow for experimenting in order to reach your KPIs. Where the partner possesses some unique expertise in the subject area and develops a unique service on top of your API, you would benefit from allowing full freedom in customizing the integration, so they might cover specific market niches and enjoy the advantage of offering more flexibility compared to using other APIs.</p><div class="page-break"></div><h3><a href="#chapter-26" class="anchor" id="chapter-26">Chapter 26. API Key Performance Indicators</a></h3>
+<p>In general, you should aim to have each partner service using the API service that maximizes your profit as an API vendor. Where the partner doesn't try to make some unique experience and needs just a typical solution, you would benefit from making them use widgets, which are under your full control and thus ease the API version fragmentation problem and allow for experimenting in order to reach your KPIs. Where the partner possesses some unique expertise in the subject area and develops a unique service on top of your API, you would benefit from allowing full freedom in customizing the integration, so they might cover specific market niches and enjoy the advantage of offering more flexibility compared to using other APIs.</p><div class="page-break"></div><h3><a href="#chapter-26" class="anchor" id="chapter-26">Chapter 26. The API Key Performance Indicators</a></h3>
 <p>As we described in the previous chapters, there are many API monetization models, both direct and indirect. Importantly, most of them are fully or conditionally free for partners, and the direct to indirect benefits ratio tends to change during the API lifecycle. That naturally leads us to the question of how exactly shall we measure the API success and what goals are to be set for the product team.</p>
 <p>Of course, the most explicit metric is money: if your API is monetized directly or attracts visitors to a monetized service, the rest of the chapter will be of little interest to you, maybe just as a case study. If, however, the contribution of the API to the company's income cannot be simply measured, you have to stick to other, synthetic, indicators.</p>
 <p>The obvious key performance indicator (KPI) No. 1 is the number of end users and the number of integrations (i.e. partners using the API). Normally, they are in some sense a business health barometer: if there is a normal competitive situation among the API suppliers, and all of them are more or less in the same position, then the figure of how many developers (and consequently, how many end users) are using the API is the main metric of the success of the API product.</p>
@@ -3447,7 +3446,7 @@ ProgramContext.dispatch = (action) => {
 <p>Additional means of tracking are users' unique identifiers, most notably cookies. However, most recently this method of gathering data is under attack from several sides: browser makers restrict third-party cookies, users are employing anti-tracker software, and lawmakers started to roll out legal requirements against data collection. In the current situation, it's much easier to drop cookie usage than to be compliant with all the regulations.</p>
 <p>All this leads to a situation when public APIs (especially those installed on free-to-use sites and applications) are very limited in the means of collecting the statistics and analyzing user behavior. And that impacts not only fighting all kinds of fraud but analyzing use cases as well. That's the way.</p>
 </li>
-</ol><div class="page-break"></div><h3><a href="#chapter-28" class="anchor" id="chapter-28">Chapter 28. Technical Means of Preventing ToS Violations</a></h3>
+</ol><div class="page-break"></div><h3><a href="#chapter-28" class="anchor" id="chapter-28">Chapter 28. The Technical Means of Preventing ToS Violations</a></h3>
 <p>Implementing the paradigm of a centralized system of preventing partner endpoints-bound fraud, which we described in the previous chapter, in practice faces non-trivial difficulties.</p>
 <p>The task of filtering out illicit API requests generally comprises three steps:</p>
 <ul>

docs/index.html

@@ -86,14 +86,14 @@
                 <h4><a href="API.en.html#section-4">Section III. The API Product</a></h4>
                 <ul>
                     <li><a href="API.en.html#chapter-20">Chapter 20. API as a Product</a></li>
-<li><a href="API.en.html#chapter-21">Chapter 21. API Business Models</a></li>
+<li><a href="API.en.html#chapter-21">Chapter 21. The API Business Models</a></li>
 <li><a href="API.en.html#chapter-22">Chapter 22. Developing a Product Vision</a></li>
 <li><a href="API.en.html#chapter-23">Chapter 23. Communicating with Developers</a></li>
 <li><a href="API.en.html#chapter-24">Chapter 24. Communicating with Business Owners</a></li>
-<li><a href="API.en.html#chapter-25">Chapter 25. API Services Range</a></li>
-<li><a href="API.en.html#chapter-26">Chapter 26. API Key Performance Indicators</a></li>
+<li><a href="API.en.html#chapter-25">Chapter 25. The API Services Range</a></li>
+<li><a href="API.en.html#chapter-26">Chapter 26. The API Key Performance Indicators</a></li>
 <li><a href="API.en.html#chapter-27">Chapter 27. Identifying Users and Preventing Fraud</a></li>
-<li><a href="API.en.html#chapter-28">Chapter 28. Technical Means of Preventing ToS Violations</a></li>
+<li><a href="API.en.html#chapter-28">Chapter 28. The Technical Means of Preventing ToS Violations</a></li>
 <li><a href="API.en.html#chapter-29">Chapter 29. Supporting customers</a></li>
 <li><a href="API.en.html#chapter-30">Chapter 30. The Documentation</a></li>
 <li><a href="API.en.html#chapter-31">Chapter 31. The Testing Environment</a></li>