Merge branch 'gh-pages' of github.com:twirl/The-API-Book into gh-pages

docs/API.en.html

@@ -467,7 +467,7 @@ Cache-Control: no-cache
 </ol>
 <p>In general, there are no simple answers to those questions. Ideally, you should give answers having all the relevant metrics measured: how much time is wasted exactly, and what numbers we're going to achieve providing we have such coffee machines density? Let us also stress that in a real-life obtaining these numbers is only possible if you're entering a stable market. If you try to create something new, your only option is to rely on your intuition.</p>
 <h4>Why an API?</h4>
-<p>Since our book is dedicated not to software development per se, but to developing APIs, we should look at all those questions from a different angle: why solving those problems specifically requires an API, not simply a specialized software application? In terms of our fictional example, we should ask ourselves: why provide a service to developers, allowing for brewing coffee to end users, instead of just making an app?</p>
+<p>Since our book is dedicated not to software development per se, but to developing APIs, we should look at all those questions from a different angle: why does solving those problems specifically require an API, not simply a specialized software application? In terms of our fictional example, we should ask ourselves: why provide a service to developers, allowing for brewing coffee to end users, instead of just making an app?</p>
 <p>In other words, there must be a solid reason to split two software development domains: there are the operators which provide APIs, and there are the operators which develop services for end users. Their interests are somehow different to such an extent, that coupling these two roles in one entity is undesirable. We will talk about the motivation to specifically provide APIs in more detail in Section III.</p>
 <p>We should also note that you should try making an API when, and only when, your answer is "because that's our area of expertise" to question 3. Developing APIs is a sort of meta-engineering: you're writing some software to allow other companies to develop software to solve users' problems. You must possess expertise in both domains (APIs and user products) to design your API well.</p>
 <p>As for our speculative example, let us imagine that in the near future some tectonic shift happened within the coffee brewing market. Two distinct player groups took shape: some companies provide ‘hardware’, i.e. coffee machines; other companies have access to customer auditory. Something like the flights market looks like: there are air companies, which actually transport passengers; and there are trip planning services where users are choosing between trip variants the system generates for them. We're aggregating hardware access to allow app vendors for ordering freshly brewed coffee.</p>

docs/API.ru.html

@@ -2484,7 +2484,7 @@ PUT /formatters/volume/ru/US
     // Раз уж мы договорились, что `name`
     // на самом деле нужен как заголовок
     // в списке результатов поиска —
-    // разумнее его так и назвать `seach_title`
+    // разумнее его так и назвать `search_title`
     "field": "search_title",
     "view": {
       // Машиночитаемое описание того,

src/ru/clean-copy/03-Раздел II. Обратная совместимость/04.md

@@ -106,7 +106,7 @@ GET /v1/layouts/{layout_id}
     // Раз уж мы договорились, что `name`
     // на самом деле нужен как заголовок
     // в списке результатов поиска —
-    // разумнее его так и назвать `seach_title`
+    // разумнее его так и назвать `search_title`
     "field": "search_title",
     "view": {
       // Машиночитаемое описание того,