From ae8a21ccf8456e6abdba9e3f3085c75212927ca0 Mon Sep 17 00:00:00 2001 From: Leonid Fedorov Date: Wed, 17 Feb 2021 19:22:00 +0300 Subject: [PATCH] fix typos --- src/ru/clean-copy/02-Раздел I. Проектирование API/05.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md b/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md index 6110f5e..cb72b72 100644 --- a/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md +++ b/src/ru/clean-copy/02-Раздел I. Проектирование API/05.md @@ -253,7 +253,7 @@ GET /coffee-machines/{id}/stocks "cup_absence": false } ``` -— то разработчику потребуется вычислить флаг `!beans_absence && !cup_absence` ⇔ `!(beans_absence || cup_absence)`, а вот этом переходе ошибиться очень легко, и избегание двойных отрицаний помогает слабо. Здесь, к сожалению, есть только общий совет «избегайте ситуаций, когда разработчику нужно вычислять такие флаги». +— то разработчику потребуется вычислить флаг `!beans_absence && !cup_absence` ⇔ `!(beans_absence || cup_absence)`, а вот в этом переходе ошибиться очень легко, и избегание двойных отрицаний помогает слабо. Здесь, к сожалению, есть только общий совет «избегайте ситуаций, когда разработчику нужно вычислять такие флаги». ##### Избегайте неявного приведения типов @@ -362,7 +362,7 @@ PATCH /v1/orders/123 * не предусмотрены ограничения на размер значений полей; * передаются бинарные данные (графика, аудио, видео и т.д.). -Во всех трёх случаях передача части полей в лучше случае замаскирует проблему, но не решит. Более оправдан следующий подход: +Во всех трёх случаях передача части полей в лучшем случае замаскирует проблему, но не решит. Более оправдан следующий подход: * для «тяжёлых» данных сделать отдельные эндпойнты; * ввести пагинацию и лимитирование значений полей; @@ -370,7 +370,7 @@ PATCH /v1/orders/123 **Во-вторых**, экономия размера ответа выйдет боком как раз при совместном редактировании: один клиент не будет видеть, какие изменения внёс другой. Вообще в 9 случаях из 10 (а фактически — всегда, когда размер ответа не оказывает значительного влияния на производительность) во всех отношениях лучше из любой модифицирующей операции возвращать полное состояние сущности в том же формате, что и из операции доступа на чтение. -**В-третьих**, этот подход может как-то работать при необходимость перезаписать поле. Но что делать, если поле требуется сбросить к значению по умолчанию? Например, как *удалить* `client_phone_number_ext`? +**В-третьих**, этот подход может как-то работать при необходимости перезаписать поле. Но что делать, если поле требуется сбросить к значению по умолчанию? Например, как *удалить* `client_phone_number_ext`? Часто в таких случаях прибегают к специальным значениям, которые означают удаление поля, например, `null`. Но, как мы разобрали выше, это плохая практика. Другой вариант — запрет необязательных полей, но это существенно усложняет дальнейшее развитие API.