API
REST-моделирование: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту: существительные vs глаголы, не-CRUD переходы, глубина вложенности, representation vs resource, идемпотентность и прагматика HATEOAS.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый — это решение, которое ты принимаешь у доски или в ревью PR: не определение для заучивания, а компромисс, который надо отстоять, когда коллега возражает.
Цель
Убедись, что связываешь моделирование ресурсов, не-CRUD переходы, глубину вложенности, разделение representation/resource, идемпотентность и прагматику HATEOAS — тот синтез, к которому вёл урок.
Викторина
Completed
Коллега предлагает GET /getOpenOrders и POST /createOrder как два новых эндпоинта. Какое возражение самое точное?
Heads-up Длина — косметика. Настоящий дефект в том, что URL несёт глагол, который HTTP-метод уже выражает — это RPC поверх HTTP, и цена — потерянный uniform interface, а не пара символов.
Heads-up Чтение должно оставаться GET, чтобы быть safe и кэшируемым; делать чтение POST-ом — скрывать, что побочных эффектов нет. Дефект — глагол в пути, а не выбор метода для создания.
Heads-up Консистентность не оправдывает RPC-форму. Как только URL называет действие, прокси и клиенты больше не могут рассуждать о нём как о resource — а в этом весь смысл REST.
Викторина
Completed
Нужно выставить 'отменить заказ' — охраняемый переход с правилами (не отгружен, не отменён ранее). Какая модель достаточно RESTful и безопасна?
Heads-up Сделать status клиент-записываемым — отдать клиенту ключи от стейт-машины: он может прыгнуть в любое состояние, обойти правила отмены и испортить состояние заказа. Переход должен охраняться на сервере.
Heads-up Отменённый заказ — не удалённый; он всё равно состоялся и несёт историю. DELETE теряет аудит-трейл и смешивает два разных исхода жизненного цикла.
Heads-up GET должен быть safe и без побочных эффектов, иначе краулер или prefetch отменит заказы. Действие, меняющее состояние, использует POST, а не GET.
Викторина
Completed
Дашборд рендерит /customers/7/projects/3/orders/42/items девятью последовательными вызовами, а путь ломается при переносе item между заказами. Какой senior-фикс?
Heads-up Кэш скрывает только латентность тёплых попаданий, инвалидация поперёк четырёх вложенных уровней зверская, а URL по-прежнему хрупкие при смене связей. Ты оптимизируешь форму, которую надо уплостить.
Heads-up Это RPC view-эндпоинт, а не resource. Каждый новый экран захочет свой, и ты дрейфуешь обратно к API «глагол на view». Field-expansion на реальных ресурсах масштабируется; эндпоинт на экран — нет.
Heads-up Вложенность выражает владение, но после одного-двух уровней навязывает chatty N+1 round-trips и хрупкие закодированные пути. Глубокое владение не требует глубоких URL — достигай resource по его собственному ID.
Викторина
Completed
API сериализует строки ORM прямо в JSON. Почему добавление явного mapping-слоя (DTO/сериализатор) — решение с наибольшим рычагом в дизайне?
Heads-up Скорость сериализации ничтожна и не в этом суть. Рычаг — разъединение: representation становится контрактом, которым ты владеешь, а не случайностью схемы.
Heads-up Обрезать колонки можно и так; трафик — побочный эффект. Реальный выигрыш — клиенты перестают зависеть от имён колонок, и БД остаётся рефакторимой.
Heads-up ORM прекрасно сериализуют связи — именно в этом риск, ведь они делают тривиальным утечку всей схемы на провод. Mapping-слой — это осознанная граница, а не обходной приём.
Викторина
Completed
Клиент ретраит POST /payments из-за таймаута ответа, и покупателя списывают дважды. Какое утверждение об идемпотентности верно?
Heads-up Идемпотентность означает, что повтор запроса даёт тот же эффект, что и один раз. PUT и DELETE подходят; POST — нет: два POST создают два resource, если не добавить idempotency key.
Heads-up GET должен быть safe (без побочных эффектов) — он вообще не может создать платёж. Safety — не то же, что дедупликация создающего запроса; нужен idempotency key на POST.
Heads-up PATCH тоже не гарантированно идемпотентен (например, патч «увеличить на 1»), и создание — не обновление. Двойное списание предотвращает idempotency key, а не ярлык метода.
Викторина
Completed
Пурист блокирует твой PR, потому что ответы не несут гипермедиа-ссылок (HATEOAS). Как senior должен это взвесить?
Heads-up Почти все production «REST» API — это level-2 по Ричардсону, без гипермедиа. HATEOAS ценен в больших hypermedia-native экосистемах, но редко стоит цены в остальных — его отсутствие не дисквалифицирует дизайн.
Heads-up Он не устарел — там, где клиенты потребляют ссылки, он реально разъединяет их со структурой URL. Он недоиспользуется, а не неверен; знай, что он даёт и когда окупается.
Heads-up Ссылки помогают только клиентам, которые реально следуют им в рантайме. Клиенты, захардкодившие URL, всё равно сломаются; гипермедиа — это дисциплина обеих сторон, а не бесплатный переключатель совместимости.
Итог
Сквозная линия: REST API моделирует существительные, нужные клиенту, с глаголом в HTTP-методе, фильтрацией и пагинацией в query-параметрах, а не-CRUD переходы — как охраняемые action- или transition-ресурсы, а не клиент-записываемое поле status. Держи вложенность мелкой и используй expansion против chatty-экранов. Сериализуй через mapping-слой, чтобы representation был контрактом, которым ты владеешь, а не твоей схемой БД. Помни, что POST не идемпотентен (используй idempotency key для безопасных ретраев), а HATEOAS — изящная теория, которая level-2 REST обычно не нужна.