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

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


http json rest restapi mime-types
person ashitaka    schedule 01.01.2009    source источник
comment
Все ответы на этот вопрос, похоже, предполагают, что задействован браузер. Мое приложение REST отправляет и отвечает сообщениями json. Вся сериализация и десериализация выполняются внутри клиента и сервера. Сторонние браузеры не имеют к этому никакого отношения, все это очень специфичная машина для очень конкретной частной машины. В этом случае application/what_type не имеет значения, это всего лишь текст. application/json подтверждает, что данные в формате json, но только в качестве комментария, и это уже самое первое, что узнают все, кто работает с API.   -  person MickeyfAgain_BeforeExitOfSO    schedule 08.02.2017
comment
@mickeyf - Тот факт, что браузеры поддерживают протокол HTTP, не означает, что приложения M2M не должны. Если вы хотите написать приложение, которое не поддерживает заголовки Accept и Content-Type (tools.ietf.org/html/rfc7231#section-3.1.1.5), вы можете это сделать, однако другие разработчики M2M могут захотеть поддерживать несколько типов мультимедиа (например, application/cbor) в стандартном способ.   -  person Dave    schedule 26.06.2018

Ответы (6)


arrow_upward
79
arrow_downward

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

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

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

person Lawrence Dol    schedule 01.01.2009
comment
Спасибо за ссылку на спецификацию JSON. Я нашел еще один вопрос о стеке, который указывает на другой тип MIME text/x-json. Не уверен, в чем разница. stackoverflow.com/questions/95554/ - person ashitaka; 01.01.2009
comment
По практическим причинам (например, у вас есть ужасный HTTP-клиент Flex) иногда вам приходится использовать 200 для всего. Однако в обычных обстоятельствах вы хотите использовать наиболее подходящий код состояния HTTP для данной ситуации. - person Bob Aman; 31.10.2009
comment
@ashitaka: Этот другой вопрос конкретно спрашивает, как установить JSON в text/x-json. Он не претендует на то, что это правильный тип носителя для JSON. - person Lawrence Dol; 25.05.2011

arrow_upward
20
arrow_downward

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

person inquam    schedule 25.05.2011

arrow_upward
10
arrow_downward

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

person Community    schedule 31.05.2009
comment
Кажется, что Дэвид ушел из SO, но может ли кто-нибудь еще поддержать вышеприведенное утверждение и привести некоторые аргументы, почему это хорошая (или плохая) практика? Согласно приведенному выше ответу Software Monkey, я вижу, что возврат ошибки HTTP с допустимым ответом JSON - неправильная идея. Сервер должен отправлять обратно ошибку HTTP только в том случае, если есть истинная ошибка. - person trejder; 18.12.2013

arrow_upward
10
arrow_downward

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

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

person Julian Reschke    schedule 25.05.2011

arrow_upward
6
arrow_downward

Правильным возвращаемым 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.

person LukeShu    schedule 01.08.2011

arrow_upward
1
arrow_downward

Если под «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 и не может быть REST API. Период.

Кроме того, из обсуждения этого поста взят следующий пример RESTful-приложения: E REST-приложение

person Jason    schedule 06.03.2018