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

59

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

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

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

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

Если код статуса HTTP остается в 200 OK?

  • 0
    Все ответы на это, кажется, предполагают, что браузер вовлечен. Мое приложение REST отправляет и отвечает сообщениями json. Вся сериализация и десериализация выполняется внутренне клиентом и сервером. Сторонние браузеры не имеют ничего общего с этим, это все очень специфическая машина для очень специфической непубличной машины. В этом случае «application / what_type» не имеет значения, все это просто текст. «application / json» подтверждает, что данные являются json, но только в качестве комментариев, и это уже первое, что знает любой, кто работает с API.
  • 1
    @mickeyf - тот факт, что браузеры поддерживают протокол HTTP, не означает, что приложения M2M не должны. Если вы хотите написать приложение, которое не поддерживает заголовки Accept и Content-Type ( tools.ietf.org/html/rfc7231#section-3.1.1.5 ), вы можете это сделать, однако другие разработчики M2M могут захотеть поддержать несколько типов мультимедиа (например, application / cbor) стандартным способом.
Теги:
rest
http
mime-types

5 ответов

67
Лучший ответ

JSON предлагает application/json, и это похоже на поддержку IETF и IANA.

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

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

  • 0
    Спасибо за ссылку на спецификацию JSON. Я нашел еще один вопрос, связанный с переполнением стека, который указывает на другой тип MIME "text / x-json". Не уверен, в чем разница. stackoverflow.com/questions/95554/...
  • 7
    По практическим причинам (скажем, например, у вас есть ужасный HTTP-клиент Flex), иногда вам приходится использовать 200 для всего. Однако при нормальных обстоятельствах вы хотите использовать наиболее подходящий код состояния HTTP для ситуации.
Показать ещё 1 комментарий
17
10

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

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

10

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

  • 2
    Кажется, что Дэвид покинул SO, но может ли кто-нибудь еще поддержать вышеприведенное утверждение и привести некоторые аргументы, почему это хорошая (или плохая) практика? Согласно ответу Software Monkey выше, я вижу, что возвращать ошибку HTTP с правильным ответом JSON - неправильная идея. Сервер должен отправлять обратно только HTTP-ошибку, если есть настоящая ошибка.
6

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню