API
Статус-коды: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажи или запиши полный ответ по памяти, прежде чем открыть модельный, — усилие припоминания и закрепляет различия, когда выбираешь код под давлением.
Реконструировать спину юнита, не подглядывая: модель «класс как машинная инструкция», раздел ответственности 4xx/5xx, почему 200-с-телом-ошибки — кардинальный грех, ловушка идемпотентности при ретраях и порядок Retry-After.
- 01Почему первая цифра статус-кода — машинная инструкция, и какие машины ветвятся по ней раньше, чем человек прочитает ответ?
- 02Объясни раздел ответственности 4xx-vs-5xx и почему это несущее различие для ретраев.
- 03Почему вернуть 200 OK с объектом-ошибкой в теле — кардинальный грех, и что именно ломается?
- 04Пройди решение о ретрае, включая ловушку идемпотентности на словившей таймаут записи.
- 05Дай порядок Retry-After для 429 и 503 и почему мгновенные ретраи опасны.
- 06Различи 401 vs 403 и 400 vs 422 и скажи, что клиенту чинить в каждом случае.
Если ты воспроизвёл каждый ответ по памяти, ты держишь спину юнита: класс — машинная инструкция, читаемая кэшами, дашбордами и циклами ретраев; 4xx — вина клиента (не ретрай), 5xx — вина сервера (может, ретрай), с 429 как ретраебельным исключением 4xx; 200-с-телом-ошибки — кардинальный грех, ведь он ослепляет каждую машину; ловушка идемпотентности превращает ретрайнутый POST на 504 в двойное списание, если не сверить или не слать ключ идемпотентности; Retry-After уважается перед бэкоффом с джиттером; а 401/400 против 403/422 говорят клиенту, переаутентифицироваться/чинить-форму или остановиться/чинить-данные.