Сообщение об ошибке в заголовке HTTP или блоке ответа?

У меня есть служба REST, которая предоставляется клиентам iPhone и Android. В настоящее время я следую HTTP-кодам 200, 400, 401, 403, 404, 409, 500 и т.д.

Мой вопрос: где рекомендуется указать причину/описание/причину ошибки? Имеет ли смысл, чтобы REST API всегда имел пользовательский разум в заголовке, как это?

< HTTP/1.1 400 Bad Request - Missing Required Parameters.
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked

Или лучше иметь его в Body Response через JSON?

< HTTP/1.1 400 Bad Request
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: application/json
{ "error" : "Missing Required Parameters" }

Ответы

Ответ 1

Цитата из спецификации HTTP для кодов ошибок 400.x:

Класс кода 4xx статуса предназначен для случаев, когда клиент похоже, ошибался. За исключением случаев ответа на запрос HEAD, сервер ДОЛЖЕН включать объект, содержащий объяснение ошибки ситуации, и является ли это временным или постоянным условием. Эти коды статуса применимы к любому методу запроса. Пользовательские агенты ДОЛЖНЫ отображение любого включенного объекта пользователю.

Лучше всего включить сообщение об ошибке как сущность в тело ответа HTTP - будь то JSON, обычный текст, форматированный HTML или любой другой формат, который вы можете использовать.

Ответ 2

Лучше иметь детали ошибки в теле. Кроме того, многие (большинство/почти все, например WSGI) серверы и клиенты не поддерживают изменение имени кода ошибки - рассматривают их как фиксированные пары (так, например, 400 всегда "плохой запрос", а не "плохой запрос" - вы Забыл указать идентификатор пользователя "). Даже если они не сломаются, они не будут заботиться о вашем специальном имени для конкретного кода ошибки.

Ответ 3

Ошибка не относится к телу. Он принадлежит в заголовке предупреждения.

Общий HTTP-заголовок Warning содержит информацию о возможных проблемах со статусом сообщения.

Ссылка

Ответ 4

Я всегда делаю то и другое. Обычно я устанавливаю сообщение статуса на то, что внешний интерфейс может показать дружественным образом пользователю, например, "409 - Не удалось добавить нового пользователя, они уже существуют".

Затем я включаю детали условий ошибки в теле как JSON, чтобы разработчики пользовательского интерфейса могли попытаться сделать разумный выбор о том, что делать.

{
  "status": 409,
  "message": "The user <username> was already added on <when> by <who> and given the user id 12345.",
  "errors": {
    "id": 12345
  }
}

Ответ 5

Если я попытался таким образом отправить ответ в веб-интерфейс, они не могут прочитать код состояния, и появляется ошибка. Но в разделе сети показан 409 ответ.

  res.status(409).json({
            status: 409,
            err_message: " already present"
          })