APIs: free-recall review
Free-recall промпты по всему треку APIs. Сначала ответь своими словами, затем открой модельный ответ и сверься с сеньорским end-to-end review.
Извлечение из памяти бьёт перечитывание. Для каждого промпта реконструируй полный ответ по памяти до того, как откроешь модельный — усилие собрать каскад заново и закрепляет его.
Реконструируй хребет трека, не подглядывая: как моделирование делает status-коды честными, почему status-код — это retry-контракт, когда cursor-пагинация обязательна, что защищает OpenAPI break-diff, где сидит протокол и как rate limit ограничивает радиус поражения.
- 01Пройди каскад: как одна ошибка моделирования ресурса становится production-outage, звено за звеном?
- 02Почему HTTP status-код — это контракт, а не украшение, и к чему каждый класс обязывает клиента?
- 03Когда cursor (keyset) пагинация обязательна вместо OFFSET/LIMIT и в чём компромисс?
- 04Что такое breaking change против аддитивного и что реально даёт spec-first OpenAPI + CI break-diff?
- 05Коллега хочет сделать публичный API на gRPC, потому что бенчмарки куда быстрее. Как рассуждать?
- 06Как rate limiting и идемпотентность вместе сдерживают retry-шторм и что обязан содержать дроссель-ответ?
Если можешь реконструировать каждый ответ по памяти, ты держишь хребет трека: моделирование существительных и есть то, что делает status-коды честными; status-коды — машиночитаемый retry-контракт, подкреплённый Idempotency-Key и Retry-After; cursor-пагинация держит большие/живые чтения плоскими и стабильными; spec-first OpenAPI с CI break-diff останавливает тихий дрейф; протокол — ортогональная ось (REST на edge, gRPC внутри); а rate limit плюс идемпотентность вместе ограничивают радиус поражения retry-шторма. Теперь, когда встретишь в ревью маршрут, status-код или запрос пагинации, ты инстинктивно спросишь: какое звено цепи это затрагивает — и на месте ли предохранители вокруг него?
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.