Повідомлення про помилку відпочинку в заголовку 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

Або краще мати його в Органі реагування через 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" }

Цитування зі специфікації HTTP для кодів помилок 400.x:

Клас коду стану 4xx призначений для випадків, коли клієнт, здається, помилився. За винятком випадків, коли відповідає на запит HEAD, сервер ПОВИНЕН включати сутність, що містить пояснення ситуації помилки, а також тимчасовий чи постійний стан. Ці коди стану застосовні до будь-якого методу запиту. Агенти користувача ПОВИННІ відображати будь-яку включену сутність для користувача.

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

Краще мати деталі помилок у тілі. Крім того, багато (більшість / майже всі, наприклад, WSGI) сервери та клієнти не підтримують зміну імені коду помилки - розглядайте їх як фіксовані пари (так, наприклад, 400 завжди є "Погане повідомлення", а не "Погане повідомлення" - Ви Забув вказати ідентифікатор користувача "). Навіть якщо вони не зламаються, їм не буде важлива ваша спеціальна назва для конкретного коду помилки.

Помилка не належить до тіла. Він належить у заголовку Попередження.

Загальний заголовок HTTP із попередженням містить інформацію про можливі проблеми зі статусом повідомлення.

Довідково