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

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

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

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

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

Спасибо!

Изменить: дополнительное предложение следующее

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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