API
APIs: спроектируй и собери production API
Прочитать каскад — не то же самое, что собрать то, что его переживёт. Спроектируй и выкати небольшой публичный API, где каждое решение держит на себе следующее — смоделируй существительные, сделай status-коды честным retry-контрактом, паджинируй курсором, зафиксируй форму в spec-first контракте с CI break-diff и закрой его rate limit — затем докажи, что каждое звено держит под retry-штормом.
Преврати весь трек в одну связную сборку: production-grade API, чьи модель ресурсов, status-коды, пагинация, контракт и rate limit спроектированы вместе, с тестами и нагрузочным прогоном, доказывающими, что швы между ними не падают.
Спроектируй и собери небольшой, но production-grade публичный API для одного домена (например платежи, заказы или контент-лента), где моделирование ресурсов, status-коды, cursor-пагинация, OpenAPI-контракт и rate limiting спроектированы как одна связанная система — затем докажи, что цепь держит под retry-штормом с доказательствами до/после.
- Автоматический тест доказывает идемпотентность: два идентичных POST с тем же Idempotency-Key создают ровно один ресурс, и второй возвращает исходный результат, а не дубликат.
- Автоматический тест прогоняет cursor-пагинацию сквозь вставки: листание списка при вставке новых строк не пропускает и не дублирует строки, а глубокие страницы стоят столько же, сколько первая.
- CI break-diff джоба продемонстрирована в обе стороны: аддитивное изменение проходит сборку, а breaking — заваливает, с захваченным выводом diff.
- Нагрузочный прогон показывает работу rate limit: запросы сверх квоты получают 429 + Retry-After (а не тихие дропы или 500), и смоделированный retry-шторм против небезопасной записи не порождает дублирующих side effects (идемпотентность + дроссель вместе).
- Разбор на одну страницу прослеживает каскад через твой API: какое решение моделирования сделало возможным какой status-код и какой guardrail (контракт, пагинация, rate limit) защищает какой нижестоящий сбой.
- Добавь демонстрацию версионирования: выкати аддитивное изменение в /v1 без bump, затем настоящий break за /v2 (или media-type версией) с заголовками Deprecation и Sunset по RFC 8594/9745, и держи v1 живым.
- Добавь внутренний gRPC-сервис за REST-edge для одной высокообъёмной операции и забенчмарь его против эквивалентного REST-вызова, показав, где сплит протокола реально окупается.
- Добавь контракт-тестирование в CI (например provider-верификацию против OpenAPI-спеки или consumer-driven контракт), чтобы работающий сервер не мог дрейфовать от спеки без падения сборки.
- Добавь наблюдаемость: структурированные логи долей 4xx/5xx, счётчиков 429, p99 latency и панель дашборда, которая дала бы дежурному заметить retry-шторм до того, как он станет outage.
Это сборка за каждым реальным публичным API: сначала существительные, чтобы status-коды могли быть честными; Idempotency-Key и верные коды, чтобы retry были безопасны; cursor-пагинация, чтобы большие/живые чтения оставались плоскими и стабильными; spec-first OpenAPI-контракт с CI break-diff, чтобы дрейф не уехал тихо; аддитивное версионирование с политикой Sunset на реальных break; REST на edge с gRPC, зарезервированным под внутренний объём; и rate limit с 429 + Retry-After, чтобы нагрузка не стала outage. Собрать это однажды как одну связанную систему — и доказать швы под retry-штормом — и есть то, что превращает ментальную модель трека в production-мышечную память.