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

Ответ 1

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

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

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

Ответ 2

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

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

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

Идеальным является реализация обоих: /resource (общий uri, поддерживающий conneg) /resource.xml /resource.json

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

Ответ 3

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

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

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

Ура!
Shonzilla

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

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

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

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

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