REST Content-Type: должен ли он основываться на расширении или заголовке Accept?

Question

Должно ли представление (html, xml, json), возвращаемое веб-службой RESTful, определяться URL-адресом или HTTP-заголовком Accept?

Answer 1

Оба действительны. Цитата xml.com :

Ресурс может иметь более одного представление. Есть четыре часто используемые способы доставки правильное представление ресурса для потребители:

1. Серверные переговоры. Поставщик услуг определяет право представление от предшествующего знания его клиенты или использует информацию предоставляется в заголовках HTTP, таких как Accept, Accept-Charset, Accept-Encoding, Accept-Language и User-Agent. недостатком этого подхода является то, что Сервер может не обладать лучшими знаниями о том, что клиент действительно хочет.
2. Клиентские переговоры. Клиент инициирует запрос к сервер. Сервер возвращает список доступно представлений. Затем клиент выбирает представление он хочет и отправляет второй запрос сервер. Недостатком является то, что клиент должен отправить два запроса.
3. Переговоры на основе прокси. Клиент инициирует запрос к серверу через прокси. Прокси передает запрос к серверу и получает список представительств. Прокси выбирает одно представление в соответствии предпочтениям, установленным клиентом и возвращает представление обратно в клиент.
4. URI-указанное представление. Клиент определяет представление это хочет в строке запроса URI.

Answer 2

Это не вопрос.

Принять зависит от подключения (согласование содержимого). Conneg позволит клиенту решать, какой тип носителя он принимает, через заголовок Accept :. Ответ будет в этом формате вместе с заголовком Vary: Accept.

С другой стороны, также возможно и совершенно правильно представить ваш ресурс как /resource.json и /resource.xml.

Идеально, чтобы реализовать оба: / ресурс (универсальный URI, который поддерживает подключение) /resource.xml /resource.json

версия подключения, возвращаемая / resource, может просто перенаправить на правильный uri в зависимости от согласованного типа носителя. В качестве альтернативы, правильное представление может быть возвращено из универсального uri и использовать Content-Location, чтобы указать возвращаемое отдельное представление.

Answer 3

Поскольку вы упоминаете веб-сервис RESTful, а не какой-либо веб-сервис, я бы настоятельно хотел использовать то, что поддерживается базовым стандартом - HTTP 1.1 и согласованием его содержимого, основанным на Accept заголовке HTTP.

Как я объяснил в своем ответе на Могу ли я изменить заголовки HTTP-запроса, отправляемого браузером , адрес (URI) и представление являются двумя опорными элементами дизайна RESTful, и они не нужно смешивать Не следует злоупотреблять URI для встраивания приемлемых представлений, когда есть Accept заголовок .

Только если ваше веб-приложение потенциально запущено и используется в среде, где некоторые промежуточные узлы используют фильтрацию HTTP-заголовков, вам следует поддерживать согласование содержимого на основе URI. По правде говоря, такие навязчивые или неправильно работающие прокси должны быть заменены, если это возможно и осуществимо.

Ура!
Shonzilla

Answer 4

Используйте заголовок Accept, если он указан, URI в качестве аварийного переключения.

Answer 5

Есть проблемы с использованием типа контента ... Я обсуждал это в своем блоге http://shouldersofgiants.co.uk/Blog и, наконец, остановился на включении представления в URI, как это было предложено в RESTful Web Services Ричардсоном и Руби

Answer 6

См. Глава 5 - Передача представительного состояния (REST) ​​, раздел 5.2.1.2 Представления диссертации Роя Филдинга по архитектурным стилям:

Формат данных представления известен как тип носителя [48] .

Глядя на ссылку, мы видим, что она относится к MIME. Поэтому я предполагаю, что на языке HTTP он представлен заголовком Content-Type для POST / PUT и заголовком Accept для GET.

Вот остальная часть абзаца (для полноты):

Представление может быть включено в сообщение и обработано получатель по данным контроля сообщения и характера типа носителя. Некоторые типы носителей предназначены для автоматизации обработки, некоторые предназначены для просмотра для просмотра пользователем, и некоторые способны на оба. Составные типы носителей могут быть использованы для заключить несколько представлений в одно сообщение.

П.С .: Я не уверен, почему люди никогда не смотрят туда, где фактически определяется REST ...

Answer 7

Поскольку очень многие URL-адреса RESTful не имеют расширения, вы должны / должны опираться на Content-Type

edit: я не хочу, чтобы это звучало так резко, как если бы вы обращали внимание на тип контента и не всегда сможете ссылаться на расширение