Какой тип MIME, если JSON возвращается REST API? - PullRequest
Новая
       93

Какой тип MIME, если JSON возвращается REST API?

66 голосов
/ 01 января 2009

Мой REST API возвращает JSON.

В настоящее время я возвращаю text / plain как тип MIME, но это забавно. Должен ли я возвращать application/x-javascript или какой-то другой тип?

Второй вопрос касается кода состояния HTTP для условий ошибки. Если мой REST API возвращает состояние ошибки, я возвращаюсь как JSON 

{ result: "fail", errorcode: 1024, errormesg: "That sucked. Try again!" }

Должен ли код состояния HTTP оставаться на 200 OK?

Ответы [ 6 ]

77 голосов
/ 01 января 2009

Спецификация JSON предлагает application/json, и это, кажется, поддерживается реестром IETF и IANA .

По второму вопросу, я думаю, что если обработка сообщения каким-то образом не удалась, вы должны вернуть структурированный и стандартный ответ об ошибке в виде сообщения JSON; только если по какой-либо причине произошла ошибка при доставке сообщения в бэкэнд-обработчик, следует учитывать код ошибки HTTP.

Обновление 2014-06-27 : Дни, когда клиенты (браузеры) работали только с ответом 200, давно прошли, и преобладающим советом для API RESTful является использование HTTP-кодов ответов, подходящих для ответа, 2xx для успешных ответов (например, 201 Создан для PUT; 204 Нет содержимого для УДАЛИТЬ) и 4xx и 5xx для всех состояний ошибки, в том числе из самого API.

19 голосов
/ 25 мая 2011
10 голосов
/ 25 мая 2011

Нет, вы не должны возвращать 200 в случае ошибки.

Можно повторить код состояния или включить более подробный код ошибки в полезную нагрузку ответа.

10 голосов
/ 31 мая 2009

Я предпочитаю отвечать и сообщением об ошибке HTTP, и информацией о приложении.

6 голосов
/ 01 августа 2011

Правильный Content-type для возврата равен application/json, в соответствии с RFC 4627 , который также регистрирует тип IANA MIME (и действительно, он отображается на странице IANA). Конечно, если вы хотите написать клиента, вы бы хотели быть более либеральным в том, что вы принимаете, а также принимать других, таких как text/json и text/x-json.

Теперь, если есть ошибка, вы должны не вернуть HTTP 200, это принципиально не RESTful. Я знаю, что иногда нет точного соответствия вашей ошибке, но выбирайте ближайшие ошибки 4XX (ошибка клиента) или 5XX (ошибка сервера) в RFC 2616, разделы 10.4 -10.5, и будьте более точными в JSON .

1 голос
/ 06 марта 2018

Если под «REST API» вы подразумеваете, что хотите следовать архитектуре REST, то тип используемого носителя определяется функциональностью, которую вы хотите предоставить через REST API. Хотите иметь возможность создавать новые объекты? Запросить список объектов? Редактировать объект? Если это так, то хорошим типом носителя RESTful для использования может быть vnd.collection + json, поскольку он определяет гипертекстовый интерфейс для управления коллекцией объектов json.

Примечание: RESTful API может использовать медиа-тип application / json, но этот медиа-тип не имеет RESTful-интерфейса с гипертекстовой связью, поэтому он будет конечной точкой в ​​изменении состояния.

Также вполне приемлемо следовать архитектуре веб-API, где вызовы HTTP RPC возвращают объекты application / json, а другие вызовы HTTP RPC манипулируют этими объектами, и нет интерфейса с гипертекстовой ссылкой для использования и навигации по изменениям состояния. Но это не ОТДЫХ.

Мне нравится это описание REST (от создателя REST):

REST APIS должен работать с гипертекстом

Другими словами, если двигатель состояния приложения (и, следовательно, API) не управляется гипертекстом, то он не может быть RESTful и не может быть API REST. Период.

Кроме того, из обсуждения этого поста приведен пример приложения RESTful: Приложение REST Lost Boys's Spam-E

...