fix

src/ru/clean-copy/02-Раздел I. Проектирование API/01.md

@@ -8,6 +8,6 @@
 
 Этот алгоритм строит API сверху вниз, от общих требований и сценариев использования до конкретной номенклатуры сущностей; фактически, двигаясь этим путем, вы получите на выходе готовое API — чем этот подход и ценен.
 
-Может показаться, что наиболее полезные советы приведены в последнем разделе, однако это не так; цена ошибки, допущенной на разных уровнях весьма различна. Если исправить плохое именование довольно просто, то исправить неверное понимание того, зачем вообще нужно API практически невозможно.
+Может показаться, что наиболее полезные советы приведены в последнем разделе, однако это не так; цена ошибки, допущенной на разных уровнях весьма различна. Если исправить плохое именование довольно просто, то исправить неверное понимание того, зачем вообще нужен API, практически невозможно.
 
 **NB**. Здесь и далее мы будем рассматривать концепции разработки API на примере некоторого гипотетического API заказа кофе в городских кофейнях. На всякий случай сразу уточним, что пример является синтетическим; в реальной ситуации, если бы такой API пришлось проектировать, он, вероятно, был бы совсем не похож на наш выдуманный пример.

src/ru/clean-copy/02-Раздел I. Проектирование API/04.md

@@ -2,7 +2,7 @@
 
 Исходя из описанного в предыдущей главе, мы понимаем, что иерархия абстракций в нашем гипотетическом проекте должна выглядеть примерно так:
 
-  * пользовательский уровень (те сущности, с которыми непосредственно взаимодействует пользователь сформулированы в понятных для него терминах; например, заказы и виды кофе);
+  * пользовательский уровень (те сущности, с которыми непосредственно взаимодействует пользователь, сформулированы в понятных для него терминах; например, заказы и виды кофе);
   * уровень исполнения программ (те сущности, которые отвечают за преобразование заказа в машинные термины);
   * уровень рантайма для API второго типа (сущности, отвечающие за state-машину выполнения заказа).
 

src/ru/clean-copy/02-Раздел I. Проектирование API/05.md

@@ -113,7 +113,7 @@ strpbrk (str1, str2)
 
 Если поле называется `recipe` — мы ожидаем, что его значением является сущность типа `Recipe`. Если поле называется `recipe_id` — мы ожидаем, что его значением является идентификатор, который мы сможем найти в составе сущности `Recipe`.
 
-То же касается и примитивных типов. Сущности-массивы должны именоваться во множественном числе или собирательными выражениями — `objects`, `children`; если это невозможно - термин неисчисляем, следует добавить префикс или постфикс, не оставляющий сомнений.
+То же касается и примитивных типов. Сущности-массивы должны именоваться во множественном числе или собирательными выражениями — `objects`, `children`; если это невозможно (термин неисчисляем), следует добавить префикс или постфикс, не оставляющий сомнений.
 
 **Плохо**: `GET /news` — неясно, будет ли получена какая-то конкретная новость или массив новостей.
 
@@ -175,7 +175,7 @@ str_replace(needle, replace, haystack)
 
 ##### Состояние системы должно быть понятно клиенту
 
-Правило можно ещё сформулировать так: не заставляйте клиента гадать.
+Правило можно ещё сформулировать так: не заставляйте разработчика клиента гадать.
 
 **Плохо**:
 ```
@@ -732,7 +732,7 @@ GET /v1/records?limit=10&offset=100
   3. Какие параметры кэширования мы можем выставить на этот эндпойнт?  
     Никакие: повторяя запрос с теми же `limit`-`offset`, мы каждый раз получаем новый набор записей.
 
-**Хорошо**: в таких однонаправленных списках пагинация должна быть организована по тому ключу, порядок которых фиксирован. Например, вот так:
+**Хорошо**: в таких однонаправленных списках пагинация должна быть организована по тому ключу, порядок сортировки по которому фиксирован. Например, вот так:
 ```
 // Возвращает указанный limit записей,
 // отсортированных по дате создания,