Подробный вопрос по REST URL

Question

Это один из тех мелких (и, возможно, религиозных) вопросов. Давайте предположим, что мы создаем REST-архитектуру, и для определенности предположим, что службе нужны три параметра: x , y и z . Читая различные работы о REST, может показаться, что это должно быть выражено в виде URI вроде

http://myservice.example.com/service/ x / y / z

Написав много CGI в прошлом, кажется вполне естественным выразить это

http://myservice.example.com/service?x=val,y=val,z=val

Есть ли какая-либо конкретная причина, чтобы предпочесть форму с косой чертой?

Answer 1

Причина невелика, но вот она.

Прохладный URI не меняется.

Форма http://myservice.example.com/resource/x/y/z/ заявляет перед Богом и всеми, что это путь к конкретному ресурсу.

Обратите внимание, что я изменил имя. Может быть, вовлечена служба, но принцип REST заключается в том, что вы описываете определенный веб-ресурс с именем /x/y/z/.

Форма http://myservice.example.com/service?x=val,y=val,z=val не является настолько сильной претензией. Там написано, что есть фрагмент кода с именем service, который попытается выполнить какой-то запрос. Нет гарантий.

Answer 2

Параметры запроса редко бывают «крутыми». Взгляните на Google Chart API. Должно ли это использовать / full / path / notation для всех полей? Будет ли каждый URL крутым, если это так?

Параметры запроса полезны. Необязательные поля могут быть опущены. Новые ключи могут быть добавлены для поддержки новых функций. Со временем старые поля могут быть устаревшими и удалены. Делать это неудобно с / path / нотацией.

Цитата из http://www.xml.com/pub/a/2004/08/11/rest.html

URI Непрозрачность [BP]

Создатель URI решает кодировку URI, и пользователи не должны получать метаданные из самого URI. Непрозрачность URI применяется только к пути URI. Строка запроса и фрагмент имеют специальные Это означает, что пользователи могут понять это. Должен быть общий словарный запас между услуга и ее потребители.

Звучит так, будто вам нужны строки запроса.

Недостатком строк запроса является то, что они неупорядочены. GET, заканчивающийся на «? X = 1 & y = 2», отличается от того, который заканчивается на «? Y = 2 & x = 1» Это означает, что браузер и любые другие промежуточные системы не смогут его кэшировать, поскольку кэширование выполняется на основе полного URL-адреса. Если это проблема, то сгенерируйте строку запроса в четко определенном порядке.

Answer 3

URI строго разделены на иерархическую часть (путь) и неиерархический путь (запрос), и оба служат для идентификации ресурса

Сама спецификация URI ( RFC 3986 ) четко устанавливает путь и часть запроса URI равными.

Раздел 3.3:

Компонент пути содержит данные [...], которые вместе с [] компонентом запроса служит для идентификации ресурса.

Раздел 3.4:

Компонент запроса содержит [...] данные, которые наряду с [...] компонент пути служит для идентификации ресурса

Таким образом, ваш выбор в использовании x/y/z против x=val&y=val&z=val в основном связан с тем, если x, y или z имеют иерархическую природу или если они не иерархические, и если вы можете воспринимать их как всегда иерархические или -иерархический в обозримом будущем, наряду с любыми техническими ограничениями, которые могут у вас возникнуть при выборе одного из другого.

Но чтобы ответить на ваш вопрос, как уже отмечали другие: ни один не является более ОТДЫХНЫМ, чем другой, поскольку оба они в конечном итоге идентифицируют ресурс.

Answer 4

При построении URI это основной принцип, которому я следую. Я не знаю, является ли это вполне приемлемым во всех случаях

Скажем, например, что я должен получить данные о сотруднике, тогда URI будет иметь вид:

GET / сотрудников / 1 / , а не GET / сотрудников? Id = 1 , поскольку я рассматриваю каждого сотрудника как ресурс и весь URI " сотрудников / {id } " используется для идентификации ресурса.

С другой стороны, если у меня есть алгоритмические операции, которые не идентифицируют конкретный ресурс как таковой, а просто требуют ввода в алгоритм, который, в свою очередь, идентифицирует ресурс, тогда я использую строки запроса.

Например, GET / employee? Empname = '% Bob%' & maxResults = 100 может дать мне всех сотрудников, в именах которых есть слово Bob, с максимальным результатом, возвращаемым запросом, ограниченным 100 .

Надеюсь, что это отвечает на ваш вопрос

Answer 5

Прежде всего, определение URI как части вашего API нарушает ограничение архитектуры REST. Вы не можете сделать это и вызвать свой API RESTful.

Во-вторых, причина, по которой параметры запроса плохи для доступа к ресурсам, не относящимся к запросу, заключается в том, что они обычно не кэшируются. Это также нарушение стандартов HTTP.

Answer 6

URL с косой чертой, такой как /x/y/z/, навязывает иерархию и не подходит для точного случая просто передачи трех параметров.

Если, как вы сказали, x y z действительно являются параметрами, а порядок не важен, было бы более целесообразно использовать точки с запятой:

http://myservice.example.com/service/x;y;z/

Если ваш «сервис», тем не менее, является просто алгоритмом, который работает одинаково с другими параметрами, также не было бы ничего плохого в использовании формата ?x=val.

Answer 7

Если ресурс является услугой, независимой от параметров, он должен быть

http://myservice.example.com/service?x=val&y=val&z=val

Это запрос GET. Один из принципов REST заключается в том, что вы ДОЛЖНЫ читать (но не изменять!) Ресурс; Вы можете POST изменить ресурс и получить ответ; вы можете PUT писать на ресурс; и вы можете удалить, чтобы удалить ресурс.

Если ресурс, специфичный для этих параметров, является постоянным ресурсом, ему нужно имя. Вы можете (если вы организовали свой веб-сервис таким образом) POST на http://myservice.example.com/service?x=val&y=val&z=val, чтобы создать конкретный экземпляр службы и вернуть ему идентификатор для имени этого экземпляра, например,

http://myservice.example.com/service/12312549

затем используйте GET / POST / PUT / DELETE для взаимодействия с этим экземпляром.