Ответ вслух Middle HTTP: методы, статусы, заголовки обновлено

Какие статусы отдавать из API

Вопрос

Как бы ты выбирал HTTP-статусы для ответов своего API? Почему не отдавать всегда 200?

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

Статус это машиночитаемый результат, на него смотрят все: клиентский код решает, показывать ли ошибку и повторять ли запрос, балансировщик и мониторинг считают долю 5xx, CDN решает, кешировать ли. Поэтому 200 с ошибкой в теле ломает экосистему.

Что должно прозвучать в ответе

  • Статус несёт смысл для клиентов, прокси, мониторинга и ретраев

  • 2xx: 200 чтение, 201 создание с Location, 204 без тела

  • 4xx ошибки клиента: 400/422 валидация, 401 и 403 разные, 404, 409 конфликт, 429 лимит

  • 5xx только когда виноват сервер: на них настраивают алерты и ретраи

  • Тело ошибки в едином формате, например Problem Details (RFC 9457)

Что могут спросить следом

  • Что отдашь, если email при регистрации уже занят?
  • Что вернёт DELETE для уже удалённого ресурса?
  • Когда уместен 202 Accepted?

Разбор

Статус это машиночитаемый результат, на него смотрят все: клиентский код решает, показывать ли ошибку и повторять ли запрос, балансировщик и мониторинг считают долю 5xx, CDN решает, кешировать ли. Поэтому 200 с ошибкой в теле ломает экосистему. Успех: 200 для чтения, 201 с Location для создания, 204 когда тела нет, 202 для долгих операций. Ошибки клиента: 400 или 422 при невалидных данных, 401 если не представился, 403 если нельзя, 404, 409 при конфликте состояния вроде занятого email, 429 при превышении лимита с Retry-After. 5xx оставляю для настоящих сбоев сервера, потому что на них срабатывают алерты. Тело ошибки делаю в одном формате, например application/problem+json.

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.