REST и несколько форматов данных - PullRequest
Новая
       10

REST и несколько форматов данных

10 голосов
/ 09 августа 2009

Хорошо, вот факт. StackOverflow реализован в REST-стиле. Когда вы посещаете конкретные вопросы / $ id / URL, вы видите вопрос. Контент возвращается в HTML, потому что это то, что понимает браузер.

Я должен разработать собственную службу REST. Факт заключается в том, что я должен вернуть несколько форматов для одной и той же информации. Например, по умолчанию может быть HTML, но я мог бы также вернуть XML или JSON.

Вопрос: какой стиль рекомендуется использовать для этого? Три варианта (больше из ваших полезных советов)

  1. опция в URL (например, http://example.com/questions/12345/?format=json)
  2. другой интерфейс (например: для данных JSON у вас есть http://example.com/questions/1234/json/ или http://example.com/json/questions/12345/, для данных XML у вас есть http://example.com/questions/1234/xml/ и т. Д. ... вы получите точку)
  3. http заголовок Принять: application / json

То же самое для операций PUT (POST). Если я хочу представить данные в разных форматах, мне нужно сообщить получателю формат, который я предоставляю, поэтому сохраняется та же ситуация (и вопрос).

Спасибо!

Редактировать : Дополнительное предложение следующее

4) Укажите правильный URL для каждого формата, например http://example.com/questions/12345.json. Это выглядит хорошо, но не значит ли это, что для согласованности у нас также должно быть http://example.com/questions/12345.html? звучит так 1995 ...:)

PS: я ненавижу уценку, выставляя произвольный порядок в списке. Если я хочу начать с 4, я смогу это сделать.

Ответы [ 3 ]

24 голосов
/ 09 августа 2009

Опция № 3, устанавливающая заголовок HTTP «Accept», больше соответствует спецификации HTTP и среди пуристов REST считается наиболее правильной. Это также означает, что вы сохраняете один и тот же URL-адрес (ресурс) независимо от того, что это за представление.

Однако вы можете столкнуться с пользовательскими агентами, которые не могут установить заголовок Accept, поэтому рекомендуется поддерживать механизм резервного копирования для указания формата ответа. В этом случае я предлагаю параметр строки URL-запроса. Использование параметра строки запроса URL-адреса означает, что вы сохраняете один и тот же основной URL-адрес независимо от типа возвращаемого содержимого. Это делает более понятным, что клиенты должны выдавать PUT только на этот URL, а не на /foo/bar.json или /foo/bar.xml URL.

Редактировать. Еще одна вещь, которую следует учитывать, если вы решите использовать суффикс URL (т.е. foo.json и foo? Format = json), это то, что у вас могут возникнуть проблемы с кэшированием прокси. Если кто-то выдает PUT для /foo.json, прокси не будет интерпретировать это как запрос на аннулирование /foo.xml. Однако, если вы используете / foo? Format = json, то все они хранятся в том же ресурсе (/ foo) в прокси.

4 голосов
/ 09 августа 2009

Я бы выбрал Вариант 1 (параметр URL), поскольку он наиболее соответствует принципам REST и наиболее прагматичен.

Вариант 2 пахнет плохо - вы говорите о разных представлениях одного и того же ресурса, поэтому вы должны использовать для них один и тот же URI.

Вариант 3 кажется слишком сложным для управления - как бы вы, например, вручную протестировали его из браузера?

(Те же аргументы применимы к PUT / POST.)

2 голосов
/ 09 августа 2009

Неважно, между 1. и 2. URI непрозрачен, поэтому от его части интерфейса REST нет никакой разницы.

С точки зрения кэширования, 1. не позволит многим кешам выполнять свою работу.

  1. хорошо, если вы хотите соединиться с несколькими представителями.

Обычно, однако, люди используют connect с заголовком Accept, возможно, с перенаправлением на полностью определенный URI, используя /customer/21.json

...