Какой тип MIME, если JSON возвращается REST API?
Мой 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?
@mickeyf - Тот факт, что браузеры поддерживают протокол HTTP, не означает, что приложения M2M не должны этого делать. Если вы хотите написать приложение, которое не поддерживает заголовки Accept и Content-Type (tools.ietf.org/html/rfc7231#section-3.1.1.5), вы можете это сделать, однако другие разработчики M2M могут захотеть поддерживать несколько типов мультимедиа (например, application / cbor) в стандарте. манера.
Ответы 6
Спецификация JSON предлагает application/json, который, похоже, поддерживается реестром IETF и IANA.
Что касается второго вопроса, я думаю, что если обработка сообщения каким-то образом не удалась, вы должны вернуть структурированный и стандартный ответ об ошибке в виде сообщения JSON; только в том случае, если по какой-то причине не удается доставить сообщение внутреннему обработчику, следует учитывать код ошибки HTTP.
Обновление 2014-06-27: Дни, когда клиенты (браузеры) работали только с ответом 200, давно прошли, и преобладающий совет для RESTful API - использовать коды ответа HTTP, подходящие для ответа, 2xx для успешных ответов (например, 201 Created for PUT; 204 No Content для DELETE) и 4xx и 5xx для всех условий ошибки, в том числе из самого API.
Спасибо за ссылку на спецификацию JSON. Я нашел еще один вопрос о стеке, который указывает на другой тип MIME «text / x-json». Не уверен, в чем разница. stackoverflow.com/questions/95554/…
По практическим соображениям (например, у вас есть ужасный HTTP-клиент Flex), иногда вам нужно использовать 200 для всего. Однако при нормальных обстоятельствах вы хотите использовать наиболее подходящий код состояния HTTP для данной ситуации.
@ashitaka: В этом другом вопросе конкретно спрашивается, как установить JSON в text / x-json. Он не утверждает, что это правильный медиа-тип для JSON.
Я предпочитаю отвечать как со статусом ошибки HTTP, так и с полезной нагрузкой приложения.
Кажется, что Дэвид покинул SO, но может ли кто-нибудь еще поддержать приведенное выше утверждение и привести некоторые аргументы, почему это хорошая (или плохая) практика? В соответствии с ответом Software Monkey выше, я вижу, что возвращение ошибки HTTP с действительным ответом JSON - неправильная идея. Сервер должен отправлять обратно HTTP-ошибку только в том случае, если есть настоящая ошибка.
Тип MIME JSON:
application/json
http://www.ietf.org/rfc/rfc4627.txt
http://www.iana.org/assignments/media-types/application/
Более конкретно здесь:
Нет, вы не должны возвращать 200 в случае ошибки.
Можно повторить код состояния или включить более подробный код ошибки в полезные данные ответа.
Правильный 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.
Если под «REST API» вы имеете в виду, что хотите следовать архитектуре REST, то используемый тип носителя определяется функциональностью, которую вы хотите предоставить через REST API. Вы хотите иметь возможность создавать новые объекты? Запросить список объектов? Редактировать объект? Если это так, то хорошим типом носителя RESTful для использования может быть vnd.collection + json, поскольку он определяет интерфейс, связанный с гипертекстом, для управления коллекцией объектов json.
Примечание. API RESTful может использовать тип мультимедиа application / json, но у этого типа мультимедиа нет интерфейса RESTful, связанного с гипертекстом, поэтому он будет конечной точкой в изменении состояния.
Также вполне допустимо следовать архитектуре веб-API, где вызовы HTTP RPC возвращают объекты application / json, а другие вызовы HTTP RPC манипулируют этими объектами, и нет интерфейса с гипертекстовой ссылкой для использования и навигации по изменениям состояния. Но это не ОТДЫХ.
Мне нравится это описание REST (от создателя REST):
REST APIS должен быть основан на гипертексте
In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.
Кроме того, из обсуждения этого сообщения приведен пример приложения RESTful: Приложение для отдыха Lost Boys's Spam-E REST
Все ответы на этот вопрос, похоже, предполагают, что задействован браузер. Мое приложение REST отправляет и отвечает сообщениями json. Вся сериализация и десериализация выполняется внутри клиента и сервера. Сторонние браузеры не имеют к этому никакого отношения, все это очень специфическая машина для очень конкретной непубличной машины. В этом случае «application / any_type» не имеет никакого значения, это всего лишь текст. «application / json» действительно подтверждает, что данные являются json, но только в качестве комментария, и это уже первое, что может знать любой, кто работает с API.