Параметры запроса URL или параметры типа мультимедиа (в заголовке Accept) для настройки ответа на запрос HTTP? - PullRequest
Новая
       13

Параметры запроса URL или параметры типа мультимедиа (в заголовке Accept) для настройки ответа на запрос HTTP?

16 голосов
/ 15 июля 2011

Я работаю над разработкой REST API, который может отвечать различными форматами, одним из которых является простой текстовый формат, который можно настроить для отображения или скрытия определенных аспектов в ответе (например, заголовков разделов или сносок).Традиционный способ сделать это - через параметры запроса URL-адреса, как для указания желаемого типа ответа, так и параметров конфигурации, например: 

http://api.example.com/foo-book/ch1/?format=text&headings=false&footnotes=true

Однако более элегантный способ RESTful указать желаемый тип ответа(вместо параметра format=text URL-запроса) следует использовать заголовок Accept, например: 

Accept: text/plain; charset=utf-8

Теперь, в дополнение к URL-адресам, типы мультимедиа могут принимать параметры для RFC 2046 и как видно в вездесущих text/html; charset=utf-8 и в Accept заголовках, подобных audio/*; q=0.2.Также показано , что созданные MIME-типы вендоров могут определять свои собственные параметры, такие как: 

application/vnd.example-com.foo+json; version=1.0
application/vnd.example-info.bar+xml; version=2.0

Так что для ранее зарегистрированных типов MIME, таких как text/html или application/json, это приемлемовключить пользовательские параметры для нужд приложения?Например: 

Accept: text/plain; charset=utf-8; headings=false; footnotes=true

Это выглядит как элегантное решение RESTful, но кажется, что оно что-то нарушает. RFC 2046 §1 говорит: 

Parameters are modifiers of the media subtype, and as such do not
fundamentally affect the nature of the content.  The set of
meaningful parameters depends on the media type and subtype.  Most
parameters are associated with a single specific subtype.  However, a
given top-level media type may define parameters which are applicable
to any subtype of that type.  Parameters may be required by their
defining media type or subtype or they may be optional.  MIME
implementations must also ignore any parameters whose names they do
not recognize.

Обратите внимание на это последнее предложение: 

MIME implementations must also ignore any parameters whose names they do not recognize.

Означает ли это, что клиент будет не соответствующим, если он признаетfootnotes=true параметр типа text/plain media?

Ответы [ 2 ]

12 голосов
/ 15 июля 2011

Мне кажется, что различие должно быть следующим:

Принять параметры заголовка относятся к упаковке ответа.

  • Тип носителя (например, application/json)
  • Кодировка символов (например, charset=utf-8)
  • Структура (например, расширения поставщика, которые указывают «тип документа»); application/vnd.example-com.foo+json; version=1.0)

Параметры запроса относятся к ресурсу (ам) по адресу.

  • Компоненты (например, заголовки и сноски)
  • Дополнительные функции (например, форматирование)
  • Ограничения (особенно при обращении к ряду подобных ресурсов)
2 голосов
/ 15 июля 2011

Дэвид Эйк прав.

Если вы изменяете возвращаемую сущность, она должна быть в URI. Все остальное сломает все виды вещей, такие как кеширование и т. Д.

«Формат» внутри URI, однако, в основном неверен. Если вы можете, используйте Accept. Заголовки ответа уже установлены, чтобы обеспечить плавный ход.

Однако, если вы не можете использовать Accept (как в стандартном веб-браузере), я рекомендую использовать расширение DOS или аналогичное для переопределения Accept. 

e.g.
/image (is the resource)
/image.jpg
/image.gif
...