API
APIs: review с выбором ответа
Суть Multiple-choice синтез по всему треку APIs — моделирование ресурсов, status-код как retry-контракт, cursor-пагинация, OpenAPI break-diff, gRPC-vs-REST и rate-limit-заголовки как один связанный дизайн.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, которые проходят сквозь весь трек. Каждый отражает решение на review реального публичного API — не определение для зубрёжки, а место, где одно слабое звено держит на себе следующее.
Цель
Убедись, что можешь проследить каскад от начала до конца: как моделирование ресурсов готовит честные status-коды, как status-коды управляют retry клиента, как пагинация и OpenAPI-контракт держат оба корректными под нагрузкой и где здесь протокол и rate limit.
Викторина
Completed
Команда смоделировала POST /chargeCard вместо ресурса payments. Через месяцы — двойные списания. Какое звено в каскаде корневое?
Heads-up Rate limit — последний guardrail, а не корень. Даже с идеальным лимитом глагольный эндпоинт, отдающий 200 на дубликаты, всё равно дважды спишет на первом же retry. Каскад начинается с моделирования.
Heads-up PUT идемпотентен лишь при полной замене ресурса с известным id; создание платежа — это POST. Идемпотентность создания даёт Idempotency-Key, а не смена метода.
Heads-up Мобильные сети падают постоянно; запрет retry меняет двойные записи на потерянные. Фикс — адресуемый ресурс плюс idempotency-ключ, делающий retry безопасным.
Викторина
Completed
Что лучше всего объясняет, почему HTTP status-код — это контракт, а не украшение?
Heads-up Приоритет обратный. Универсальные клиенты и SDK ветвятся по status-коду и заголовкам, не парся тело; код — машиночитаемая часть контракта.
Heads-up Отдавать 200 с ошибкой в теле — классический антипаттерн: retry-логика, кэши и мониторинг читают 200 как успех и не видят сбой. Код обязан отражать исход.
Heads-up 5xx безопасно ретраить только при идемпотентной операции. Retry неидемпотентного POST на 5xx, пришедший после записи, и есть способ списать дважды.
Викторина
Completed
Эндпоинт отдаёт список на 2M строк, просматриваемый вживую, через OFFSET/LIMIT, и глубокие страницы тормозят и иногда пропускают строки. Лучший структурный фикс?
Heads-up Индекс помогает ORDER BY, но OFFSET 100000 всё равно заставляет БД просканировать и отбросить 100k строк на каждой глубокой странице. Стоимость растёт с глубиной независимо от индекса.
Heads-up Кэш живого пагинированного списка отдаёт устаревшие, дрейфующие страницы и ничего не даёт длинному хвосту уникальных глубоких страниц. Keyset убирает медленный путь структурно.
Heads-up Это прячет симптом и ломает легитимный глубокий просмотр. Cursor-пагинация устраняет медленную часть, а не огораживает её.
Викторина
Completed
Деплой переименовал поле конверта ошибки с `message` на `detail` и ужесточил enum статуса. CI был зелёный, а клиенты сломались в проде. Чего не хватало и какие изменения были проблемой?
Heads-up Обратная совместимость значит, что немодифицированный старый клиент продолжает работать. Переименование поля и ужесточение enum ломают это по определению — контракт сломал продюсер, а не консьюмер.
Heads-up Переименование (удаление старого имени) и ужесточение валидации — breaking, а не аддитивные. Аддитивное — это добавление опционального поля или нового значения enum, которое клиент может игнорировать.
Heads-up Тесты под старую форму остались зелёными именно потому, что их не перегенерировали из спеки. Фикс — машинный diff новой спеки против старой, а не удаление тестов.
Викторина
Completed
Коллега хочет сделать публичный API на gRPC, потому что бенчмарки показывают ~77% ниже latency, ~10x меньше сообщения и выше throughput. Как рассуждать сеньору?
Heads-up Raw latency — не то ограничение, под которое оптимизируется публичный API. На публичном edge gRPC убивает discoverability, ломает доступ через curl/браузер и повышает порог входа для внешних разработчиков.
Heads-up На 40k req/s с крошечными payload и стримингом JSON-over-HTTP жжёт лишние CPU, память и трафик и не имеет first-class стриминга. Внутренний хоп — единственное место, где числа gRPC реально важны.
Heads-up GraphQL решает over/under-fetching под форму клиента; он не закрывает высокопроизводительный внутренний стриминговый хоп и добавляет проблемы query-complexity и кэширования на публичном edge. Это другой инструмент, а не замена.
Викторина
Completed
Retry-шторм на пике превращается в outage: десятки тысяч дублирующих записей в секунду бьют в БД. Какой контроль сдержал бы это и как он должен вести себя?
Heads-up Голый 503 без Retry-After оставляет клиентам гадать; многие ретраят сразу и усиливают шторм. Дроссель обязан сказать клиенту, когда вернуться, через Retry-After.
Heads-up Тихий дроп выглядит как сетевой сбой, что провоцирует ещё больше retry и полностью прячет лимит от клиента. 429 с Retry-After — явный, машиночитаемый сигнал отступить.
Heads-up Без Retry-After клиенты откатываются на свой (часто агрессивный или фиксированный) backoff, и документированная квота превращается в гадание. Заголовок и делает backoff кооперативным.
Итог
Трек — это одна цепь, а не чеклист. Моделирование ресурсов (существительные, не-CRUD-действия как суб-ресурсы) решает, могут ли status-коды быть честными; status-коды — машиночитаемый retry-контракт (201/409/429, Idempotency-Key на небезопасных записях, Retry-After на дросселях); cursor-пагинация держит большие/живые чтения плоскими и стабильными; spec-first OpenAPI с break-diff в CI останавливает тихий дрейф; версионирование развивается аддитивно и поднимает версию только на реальных break с политикой Sunset; протокол — ортогональная ось (REST на edge, gRPC внутри); rate limit с 429 + Retry-After не даёт retry-шторму стать outage. Ревьюй каскад, потому что каждое звено держит следующее.