В чем разница между респонс-кодами 200,201 и 204?

Разница между HTTP-кодами 200 OK, 201 Created и 204 No Content

HTTP-статусы 200, 201 и 204 относятся к классу успешных ответов (2xx), но имеют важные семантические различия, которые критичны для проектирования RESTful API и корректной работы клиент-серверного взаимодействия.

Основные характеристики каждого кода

200 OK — универсальный код успешного выполнения запроса. Сервер подтверждает, что запрос был обработан без ошибок, и в теле ответа почти всегда передаются данные, запрошенные клиентом или сгенерированные в результате операции.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "John Doe",
  "status": "active"
}

Типичные случаи использования:

• Успешный GET-запрос для получения ресурса или коллекции.
• Успешный PUT или PATCH-запрос для обновления ресурса, когда сервер возвращает обновлённое представление.
• Успешный POST-запрос, не приводящий к созданию нового ресурса (например, запуск процесса, расчёт данных).

201 Created — указывает, что запрос (обычно POST или PUT) успешно выполнился и привёл к созданию одного или нескольких новых ресурсов на сервере. Это важное соглашение REST, информирующее клиента об успешной креации. Ответ должен содержать заголовок Location с URI созданного ресурса. Тело ответа часто (но не всегда) содержит представление нового ресурса.

HTTP/1.1 201 Created
Location: /api/users/456
Content-Type: application/json

{
  "id": 456,
  "name": "Jane Smith",
  "createdAt": "2023-10-26T12:00:00Z"
}

Типичные случаи использования:

• Успешный POST-запрос на создание нового элемента в коллекции (например, добавление пользователя).
• Успешный PUT-запрос на создание ресурса по известному URI (идемпотентное создание).

204 No Content — информирует клиента, что запрос выполнен успешно, но сервер не возвращает никакого контента в теле ответа. Это часто используется в операциях, где клиенту не требуется дополнительная информация от сервера, кроме факта успеха.

HTTP/1.1 204 No Content

Типичные случаи использования:

• Успешный DELETE-запрос (ресурс удалён, возвращать нечего).
• Успешный PUT или PATCH-запрос, когда клиенту не требуется обновлённое представление ресурса.
• Операции, которые не меняют состояние клиента, кроме факта успеха (например, отправка лога, подтверждение получения уведомления).

Сводная таблица различий

Практические рекомендации для QA-инженера

1. Валидация ответов: При тестировании API необходимо проверять не только факт успешного ответа, но и соответствие кода состояния семантике операции. Например, POST на создание должен вернуть 201, а не 200 с данными.
2. Проверка заголовков: Для статуса 201 обязательна проверка наличия и корректности заголовка Location. Его отсутствие — потенциальный баг.
3. Проверка тела ответа: Для 204 нужно убедиться, что тело ответа полностью пустое. Даже лишний пробел или перевод строки могут нарушить ожидания некоторых клиентов.
4. Тестирование граничных случаев: Как поведёт себя система, если при 204 сервер по ошибке отправит тело? Примет ли клиент 200 вместо 201? Это точки потенциальной несовместимости.
5. Документация: Часто несоответствия возникают из-за расхождений между заявленным в спецификации API и фактическим поведением. QA-инженер должен сверять реальные ответы с документацией.

Понимание этих нюансов позволяет не только находить баги, но и способствовать созданию более корректного, предсказуемого и удобного для потребления API, что напрямую влияет на качество интеграций и работу клиентских приложений.