Хорошо, вот что. 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 (параметр URL), поскольку он наиболее соответствует принципам REST и наиболее прагматичным.
Вариант 2 плохо пахнет - вы говорите о разных представлениях одного и того же ресурса, поэтому вы должны использовать для них один и тот же URI.
Вариант 3 может быть слишком сложным для контроля - как бы вы проверили его из своего браузера, например?
(Те же аргументы применимы к PUT/POST.)
Вариант № 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) в прокси.
Это не имеет значения ни малейшим образом между 1. и 2. URI непрозрачен, поэтому из его части интерфейса REST нет никакой разницы.
С точки зрения кэширования, 1. предотвратит выполнение многими кешами своей работы.
Обычно люди используют conneg с заголовком Accept, возможно, с переадресацией на полный URI с использованием/customer/21.json