API
APIs: free-recall 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-шторма. Это один каскад, ревьюимый как цепь.