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

вопрос создан в Sat, May 11, 2013 12:00 AM

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

    
66
  1. Кажется, что все ответы на это предполагают, что браузер вовлечен. Мое приложение REST отправляет и отвечает сообщениями json. Вся сериализация и десериализация выполняется внутренне клиентом и сервером. Сторонние браузеры не имеют ничего общего с этим, это все очень специфическая машина для очень специфической непубличной машины. В этом случае «application /what_type» не имеет значения, все это просто текст. «application /json» подтверждает, что данные являются json, но только в качестве комментариев, и это уже первое, что может знать любой, кто работает с API.
    2017-02-08 15: 32: 03Z
  2. @ mickeyf - тот факт, что браузеры поддерживают протокол HTTP, не означает, что приложения M2M не должны. Если вы хотите написать приложение, которое не поддерживает заголовки Accept и Content-Type ( tools.ietf.org/html/rfc7231#section-3.1.1.5 ) вы можете это сделать, однако другие разработчики M2M могут захотеть поддерживать несколько типов мультимедиа (например, application /cbor) в стандартном образом.
    2018-06-25 21: 08: 32Z
6 ответов                              6                         

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

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

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

    
77
2014-06-27 20: 57: 10Z
  1. Спасибо за ссылку на спецификацию JSON. Я нашел еще один вопрос, связанный с переполнением стека, который указывает на другой тип MIME "text /x-json". Не уверен, в чем разница. stackoverflow.com/questions/95554/…
    2009-01-01 03: 38: 57Z
  2. По практическим причинам (скажем, например, у вас есть ужасный HTTP-клиент Flex в миксе), иногда вам приходится использовать 200 для всего. Однако при нормальных обстоятельствах вы хотите использовать наиболее подходящий код состояния HTTP для ситуации.
    2009-10-31 05: 08: 24Z
  3. @ ashitaka: В этом другом вопросе конкретно задается вопрос о том, как установить JSON в text /x-json. Он не претендует на то, что это правильный медиа-тип для JSON.
    2011-05-25 18: 50: 17Z

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

    
19
2011-05-25 08: 39: 06Z

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

    
10
2009-05-31 18: 13: 35Z
  1. Кажется, что Дэвид покинул SO, но может ли кто-нибудь еще поддержать приведенное выше утверждение и привести некоторые аргументы, почему это хорошая (или плохая) практика? Согласно ответу Software Monkey выше, я вижу, что возвращать ошибку HTTP с правильным ответом JSON - неправильная идея. Сервер должен отправлять обратно только HTTP-ошибку, если есть настоящая ошибка.
    2013-12-18 10: 00: 01Z

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

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

    
10
2011-05-25 09: 25: 03Z

Правильный 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.

    
6
2011-08-01 19: 15: 24Z

Если под «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: Lost Мальчики Спам-E RESTПрименение р>     

1
2018-03-06 04: 35: 35Z
источник размещен Вот