Я работаю над созданием RESTful API. Мы знаем, что хотим вернуть JSON и XML для любого ресурса. Я думал, что мы сделаем что-то вроде этого:
GET /api/something?param1=value1
Accept: application/xml (or application/json)
Однако кто-то бросил использовать расширения для этого, например, так:
GET /api/something.xml?parm1=value1 (or /api/something.json?param1=value1)
Каковы компромиссы с этими подходами? Лучше ли полагаться на заголовок accept, когда расширение не указано, но соблюдать расширения, когда оно указано? Есть ли недостаток этого подхода?
architecture
web-services
rest
http
Брэндон Линтон
источник
источник
Ответы:
Это, «Однако, философски - первый подход - единственный подход», и это «Правильный официальный подход RESTful - использовать Accept: header». которые широко воспринимаются как дело, но и абсолютно неверно .
Вот краткий фрагмент Роя Филдинга (который определил REST) ...
«в разделе 6.2.1 не сказано, что согласование контента должно использоваться постоянно». цитировать
Этот конкретный разговор находится в контексте заголовка «Accept-Language:», но то же самое относится в равной степени к заголовку «Accept:», как было ясно позже в его ответе ...
«Я понятия не имею, почему люди не видят вторую и третью ссылку на верхней странице
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
это указывает на два издания PDF. "
Он имеет в виду, что нет проблем в использовании разных конечных точек для разных представлений одних и тех же исходных данных. (В этом случае одна конечная точка .html и две разные конечные точки .pdf.)
Также в аналогичном обсуждении, на этот раз о преимуществах использования параметров запроса по сравнению с использованием расширений файлов для различных типов медиа ...
«Вот почему я всегда предпочитаю расширения. Ни один из вариантов не имеет ничего общего с REST». цитировать
Опять же, это немного отличается от Accept против расширений имени файла, но позиция Филдинга все еще ясна.
Ответ - это действительно не имеет большого значения. Компромиссы между этими двумя не очень существенны, и оба - приемлемые стили.
источник
Надлежащим официальным подходом RESTful является использование
Accept:заголовка.Однако вы должны быть осторожны, чтобы не нарушить кешируемость, что является одним из требований REST. Вы должны иметь
Vary: Acceptзаголовок и кеш, который понимает это. В идеальном мире это было бы у вас, но в реальной жизни ваш опыт может варьироваться. Поэтому второе решение не такое чистое, но оно может быть более практичным.Также обратите внимание, что некоторые очень старые браузеры игнорировали заголовки, вместо этого полагаясь на расширение.
источник
Технически это на самом деле не имеет значения - ваш веб-сервер сможет пройти процесс соответствующим образом, как он выглядит. (Я предполагаю, что это не похоже на showtopper).
Однако философски - первый подход - единственный подход. В REST URL фактически указывает только на URI, который является только ресурсом. Задумайтесь на мгновение этот ресурс такой же , как объект в объектно - ориентированном программировании. Вы общаетесь с этим ресурсом только через 4 метода (иначе говоря, GET / POST / PUT / DELETE -или, если это позволяет транспорт), но этот метод не становится описанием объекта. Точно так же аспекты возвращаемого значения не являются URI. Объект все еще что-то, а не что- то. Xml или что-то.
Предположим, что если вы не хотите использовать заголовок Accept, но если вы все еще хотите быть по-настоящему REST по-философски, я не возражаю против чего-то вроде:
в отличие от
Но, как я уже сказал, это различие только философское.
источник
@vartec: я думаю ты ошибаешься
Надлежащий официальный принцип RESTful гласит, что ничего не должно быть скрыто в заголовках HTTP, так как это URI, который предоставляется или на который ссылаются, любая информация о запросе / ответе должна предоставляться как часть URI.
Поэтому я настоятельно рекомендую избегать использования заголовка для деталей, которые касаются запроса и ответа, и придерживаться
Я не могу быстро найти ссылки, но я буду публиковать их обратно (на самом деле вы можете сослаться на книгу публикации O'reilly "RESTful web services" ( http://shop.oreilly.com/product/9780596529260.do ) что подтверждает то же самое
источник