corrections

docs/API.en.html

@@ -638,7 +638,7 @@ ul.references li p a.back-anchor {
 <li>Either the client-server interaction heavily relies on the features described in the HTTP standard (or rather standards, as the functionality is split across several different RFCs), or</li>
 <li>HTTP is used as transport, and there is an additional abstraction level built upon it (i.e., the HTTP capabilities, such as the headers and status codes nomenclatures, are deliberately reduced to a bare minimum, and all the metadata is handled by the higher-level protocol).</li>
 </ul>
-<p>The APIs that belong to the first category are usually denoted as “REST” or “RESTful” APIs. The second category comprises different RPC formats and some service protocols, for example, SSH.</p>
+<p>The APIs that belong to the first category are usually denoted as “REST” or “RESTful” APIs. The second category comprises mostly different RPC formats.</p>
 <p><strong>Second</strong>, different HTTP APIs rely on different data formats:</p>
 <ul>
 <li>REST APIs and some RPCs (<a href="https://www.jsonrpc.org/">JSON-RPC</a>, <a href="https://graphql.org/">GraphQL</a>, etc.) use the <a href="https://www.ecma-international.org/publications-and-standards/standards/ecma-404/">JSON</a> format (sometimes with some additional endpoints to transfer binary data)</li>

docs/API.ru.html

@@ -638,7 +638,7 @@ ul.references li p a.back-anchor {
 <li>либо клиент-серверное взаимодействие опирается на описанные в стандарте HTTP возможности (точнее было бы сказать, «стандартах HTTP», поскольку функциональность протокола описана во множестве разных RFC);</li>
 <li>либо HTTP утилизируется как транспорт, и поверх него выстроен дополнительный уровень абстракции (т.е. возможности HTTP, такие как номенклатура ошибок или заголовков, сознательно редуцируются до минимального уровня, а вся мета-информация переносится на уровень вышестоящего протокола).</li>
 </ul>
-<p>К первой категории относятся API, которые принято обозначать словом «REST» или «RESTful», а ко второй — все виды RPC, а также прикладные протоколы типа SSH.</p>
+<p>К первой категории относятся API, которые принято обозначать словом «REST» или «RESTful». Вторая категория, в основном, представлена разными видами RPC-протоколов.</p>
 <p><strong>Во-вторых</strong>, реализации HTTP API опираются на разные форматы передаваемых данных:</p>
 <ul>
 <li>REST API и некоторые RPC (<a href="https://www.jsonrpc.org/">JSON-RPC</a>, <a href="https://graphql.org/">GraphQL</a>) полагаются в основном на формат <a href="https://www.ecma-international.org/publications-and-standards/standards/ecma-404/">JSON</a> (опционально дополненный передачей бинарных файлов);</li>

src/en/clean-copy/01-Introduction/03.md

@@ -1,4 +1,4 @@
-### [Overview of Existing API Development Solutions][intro-api-solutions-overview]
+### [An Overview of Existing API Development Solutions][intro-api-solutions-overview]
 
 In the first three sections of this book, we aim to discuss API design in general, not bound to any specific technology. The concepts we describe are equally applicable to, let's say, web services and operating system (OS) APIs.
 
@@ -27,7 +27,7 @@ All the above-mentioned technologies operate in significantly dissimilar paradig
 
 #### SDKs
 
-The term “SDK” (stands for “Software Development Kit”) is not, strictly speaking, related to APIs: this is a generic term for a software toolkit. As with “REST,” however, it got some popular reading as a client framework to work with some underlying API. This might be, for example, a wrapper to a client-server API or a UI to some OS API. The major difference from the APIs we discussed in the previous paragraph is that an “SDK” is implemented for a specific programming language and platform, and its purpose is translating the abstract language-agnostic set methods (comprising a client-server or an OS API) into concrete structures specific for the programming language and the platform.
+The term “SDK” (stands for “Software Development Kit”) is not, strictly speaking, related to APIs: this is a generic term for a software toolkit. As with “REST,” however, it got some popular reading as a client framework to work with some underlying API. This might be, for example, a wrapper to a client-server API or a UI to some OS API. The major difference from the APIs we discussed in the previous paragraph is that an “SDK” is implemented for a specific programming language and platform to work with some underlying low-level API.
 
 Unlike client-server APIs, such SDKs can hardly be generalized as each of them is developed for a specific language-platform pair. Interoperable SDKs exist, notably cross-platform mobile ([React Native](https://reactnative.dev/), [Flutter](https://flutter.dev/), [Xamarin](https://dotnet.microsoft.com/en-us/apps/xamarin), etc.) and desktop ([JavaFX](https://openjfx.io/), [QT](https://www.qt.io/), etc.) frameworks and some highly-specialized solutions ([Unity](https://docs.unity3d.com/Manual/index.html)). However, they are still narrowly focused on concrete technologies.
 

src/en/clean-copy/05-Section IV. HTTP APIs & the REST Architectural Principles/06.md

@@ -1,4 +1,4 @@
-### [Designing a Nomenclature of URLs. CRUD Operations][http-api-urls-crud]
+### [Designing a Nomenclature of URLs. The CRUD Operations][http-api-urls-crud]
 
 As we noted on several occasions in the previous chapters, neither the HTTP and URL standards nor REST architectural principles prescribe concrete semantics for the meaningful parts of a URL (notably, path fragments and key-value pairs in the query). **The rules for organizing URLs in an HTTP API exist *only* to improve the API's readability and consistency from the developers' perspective**. However, this doesn't mean they are unimportant. Quite the opposite: URLs in HTTP APIs are a means of describing abstraction levels and entities' responsibility areas. A well-designed API hierarchy should be reflected in a well-designed URL nomenclature.
 

src/en/clean-copy/07-Section VI. The API Product/01.md

@@ -1,4 +1,4 @@
-### [API as a Product][api-product]
+### [The API as a Product][api-product]
 
 There are two important statements regarding APIs viewed as products.
 

src/en/clean-copy/07-Section VI. The API Product/02.md

@@ -1,4 +1,4 @@
-### [The API Business Models][api-product-business-models]
+### [API Business Models][api-product-business-models]
 
 Before we proceed to the API product management principles, let us draw your attention to the matter of profits that the API vendor company might extract from it. As we will demonstrate in the next chapters, this is not an idle question as it directly affects making product decisions and setting KPIs for the API team. In this chapter, we will enumerate the main API monetization models. [In brackets, we will provide examples of such models applicable to our coffee-machine API study.]
 

src/en/clean-copy/07-Section VI. The API Product/06.md

@@ -1,4 +1,4 @@
-### [The API Services Range][api-product-range]
+### [An API Services Range][api-product-range]
 
 The important rule of API product management any major API provider will soon learn is: don't just ship one specific API; there is always room for a range of products, and this range is two-dimensional.
 

src/en/clean-copy/07-Section VI. The API Product/07.md

@@ -1,4 +1,4 @@
-### [The API Key Performance Indicators][api-product-kpi]
+### [API Key Performance Indicators][api-product-kpi]
 
 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.
 

src/en/clean-copy/07-Section VI. The API Product/12.md

@@ -1,4 +1,4 @@
-### [The Testing Environment][api-product-testing]
+### [Testing Environments][api-product-testing]
 
 If the operations executed via the API imply consequences for end users or partners (cost money, in particular) you must provide a test version of the API. In this testing API, real-world actions either don't happen at all (for instance, orders are created but nobody serves them) or are simulated by cheaper means (let's say, instead of sending an SMS to a user, an email is sent to the developer's mailbox).
 

src/ru/clean-copy/01-Введение/03.md

@@ -29,7 +29,7 @@ HTTP API будет посвящён раздел IV; мы также отдел
 
 #### SDK
 
-Понятие SDK (Software Development Kit, «набор для разработки программного обеспечения»), вообще говоря, вовсе не относится к API: это просто термин для некоторого набора программных инструментов. Однако, как и за «REST», за ним закрепилось некоторое определённое толкование — как клиентского фреймворка для работы с некоторым API. Это может быть как обёртка над клиент-серверным API, так и UI-библиотека в рамках какой-то платформы. Существенным отличием от вышеперечисленных API является то, что «SDK» реализован для какого-то конкретного языка программирования, и его целью является как раз превращение абстрактного набора методов (клиент-серверного API или API операционной системы) в конкретные структуры, разработанные для конкретного языка программирования и конкретной платформы.
+Понятие SDK (Software Development Kit, «набор для разработки программного обеспечения»), вообще говоря, вовсе не относится к API: это просто термин для некоторого набора программных инструментов. Однако, как и за «REST», за ним закрепилось некоторое определённое толкование — как клиентского фреймворка для работы с некоторым API. Это может быть как обёртка над клиент-серверным API, так и UI-библиотека в рамках какой-то платформы. Существенным отличием от вышеперечисленных API является то, что «SDK» реализован для какого-то конкретного языка программирования и предоставляет возможность работать с низкоуровневым API нижележащей платформы.
 
 В отличие от клиент-серверных API, обобщить такие SDK не представляется возможным, т.к. каждый из них написан под конкретное сочетание язык программирования-платформа. Из интероперабельных технологий в мире SDK можно привести в пример кросс-платформенные мобильные ([React Native](https://reactnative.dev/), [Flutter](https://flutter.dev/), [Xamarin](https://dotnet.microsoft.com/en-us/apps/xamarin)) и десктопные фреймворки ([JavaFX](https://openjfx.io/), QT) и некоторые узкоспециализированные решения ([Unity](https://docs.unity3d.com/Manual/index.html)), однако все они направлены на работу с конкретными технологиями и весьма специфичны.