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

Question

Мой 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?

Answer 1

Тот Самый JSON спецификация предполагает application/json, и это , по - видимому , подтверждается IETF и ИАНА реестр.

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

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

Answer 2

MIME-тип JSON - это

application/json

http://www.ietf.org/rfc/rfc4627.txt

http://www.iana.org/assignments/media-types/application/

Более конкретно здесь:

http://www.ietf.org/rfc/rfc4627.txt

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

REST API должны управляться гипертекстом

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

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