From a09c7514ee30030ff710efe2b4bf2504cc3096da Mon Sep 17 00:00:00 2001 From: Sergey Konstantinov Date: Thu, 9 Dec 2021 22:28:48 +0300 Subject: [PATCH] fix --- src/ru/clean-copy/02-Раздел I. Проектирование API/01.md | 2 +- src/ru/clean-copy/02-Раздел I. Проектирование API/04.md | 2 +- src/ru/clean-copy/02-Раздел I. Проектирование API/05.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/src/ru/clean-copy/02-Раздел I. Проектирование API/01.md b/src/ru/clean-copy/02-Раздел I. Проектирование API/01.md index 4037bd7..15b1492 100644 --- a/src/ru/clean-copy/02-Раздел I. Проектирование API/01.md +++ b/src/ru/clean-copy/02-Раздел I. Проектирование API/01.md @@ -8,6 +8,6 @@ Этот алгоритм строит API сверху вниз, от общих требований и сценариев использования до конкретной номенклатуры сущностей; фактически, двигаясь этим путем, вы получите на выходе готовое API — чем этот подход и ценен. -Может показаться, что наиболее полезные советы приведены в последнем разделе, однако это не так; цена ошибки, допущенной на разных уровнях весьма различна. Если исправить плохое именование довольно просто, то исправить неверное понимание того, зачем вообще нужно API практически невозможно. +Может показаться, что наиболее полезные советы приведены в последнем разделе, однако это не так; цена ошибки, допущенной на разных уровнях весьма различна. Если исправить плохое именование довольно просто, то исправить неверное понимание того, зачем вообще нужен API, практически невозможно. **NB**. Здесь и далее мы будем рассматривать концепции разработки API на примере некоторого гипотетического API заказа кофе в городских кофейнях. На всякий случай сразу уточним, что пример является синтетическим; в реальной ситуации, если бы такой API пришлось проектировать, он, вероятно, был бы совсем не похож на наш выдуманный пример. diff --git a/src/ru/clean-copy/02-Раздел I. Проектирование API/04.md b/src/ru/clean-copy/02-Раздел I. Проектирование API/04.md index a37368e..31f1720 100644 --- a/src/ru/clean-copy/02-Раздел I. Проектирование API/04.md +++ b/src/ru/clean-copy/02-Раздел I. Проектирование API/04.md @@ -2,7 +2,7 @@ Исходя из описанного в предыдущей главе, мы понимаем, что иерархия абстракций в нашем гипотетическом проекте должна выглядеть примерно так: - * пользовательский уровень (те сущности, с которыми непосредственно взаимодействует пользователь сформулированы в понятных для него терминах; например, заказы и виды кофе); + * пользовательский уровень (те сущности, с которыми непосредственно взаимодействует пользователь, сформулированы в понятных для него терминах; например, заказы и виды кофе); * уровень исполнения программ (те сущности, которые отвечают за преобразование заказа в машинные термины); * уровень рантайма для API второго типа (сущности, отвечающие за state-машину выполнения заказа). diff --git a/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md b/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md index 6506402..2e00469 100644 --- a/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md +++ b/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 записей, // отсортированных по дате создания,