Подтвердить что ты не робот

Стандарт останова: параметры пути или параметры запроса

Я создаю новую службу REST.

Каков стандарт передачи параметров сервисам REST. Из разных реализаций REST в Java вы можете настроить параметры как часть пути или как параметры запроса. Например,

Параметры пути http://www.rest.services.com/item/b

Параметры запроса http://www.rest.services.com/get?item=b

Кто-нибудь знает, какие преимущества/недостатки для каждого метода передачи параметров. Кажется, что передача параметров как части пути, по-видимому, лучше совпадает с понятием протокола REST. То есть, единственное местоположение означает уникальный ответ, правильно?

4b9b3361

ОТВЕТЫ

Ответ 1

Контуры, как правило, кэшируются, параметры, как правило, не являются, как правило.

Итак...

GET /customers/bob

против

GET /customers?name=bob

Первое, скорее всего, будет кэшироваться (при условии правильности заголовков и т.д.), в то время как последнее, скорее всего, не будет кэшироваться.

Ответ 2

tl; dr: Возможно, вы захотите обоим.

Пункт № 42 существует:

GET /items/42
Accept: application/vnd.foo.item+json
--> 200 OK
{
    "id": 42,
    "bar": "baz"
}

GET /items?id=42
Accept: application/vnd.foo.item-list+json
--> 200 OK
[
    {
        "id": 42,
        "bar": "baz"
    }
]

Элемент № 99 не существует:

GET /items/99
Accept: application/vnd.foo.item+json
--> 404 Not Found

GET /items?id=99
Accept: application/vnd.foo.item-list+json
--> 200 OK
[
]

Пояснения и комментарии

  • /items/{id} возвращает item, а /items?id={id} возвращает item-list.
  • Даже если в отфильтрованном item-list имеется только один элемент, список элементов остается неизменным (в отличие от самого элемента).
  • Так получилось, что id является уникальным свойством. Если мы будем фильтровать другие свойства, это будет работать точно так же.
  • Элементы ресурса коллекции могут быть названы только с использованием уникальных свойств (например, ключей как подресурсов коллекции) по понятным причинам (они являются обычными ресурсами, а URI однозначно идентифицируют ресурсы).
  • Если элемент не найден при использовании фильтра, ответ остается OK и по-прежнему содержит список (хотя и пустой). Просто потому, что мы запрашиваем отфильтрованный список, содержащий элемент, который не существует, не означает, что сам список не существует.

Потому что они настолько разные и независимо друг от друга полезны, вам могут понадобиться как. Клиент хочет различать все случаи (например, является ли список пустым или сам список не существует, и в этом случае вы должны вернуть 404 для /items?...).

Отказ от ответственности: Этот подход ни в коем случае не является "стандартным". Это имеет для меня такой смысл, хотя я чувствовал, что разделяю.

PS: Именование коллекции предметов "get" - это запах кода; предпочитают "предметы" или подобные.

Ответ 3

Второй пример "параметров запроса" неверен, потому что "get" включен как часть пути. GET - это тип запроса, он не должен быть частью пути.

Существует 4 основных типа запросов:

 GET
 PUT
 POST
 DELETE

Запросы GET всегда должны быть заполнены без какой-либо информации в теле запроса. Кроме того, запросы GET должны быть "безопасными", что означает, что никакие существенные данные не изменяются запросом.

Помимо упомянутого выше проблемы кэширования, параметры в пути URL-адреса, как правило, потребуются и/или ожидаются, потому что они также являются частью вашей маршрутизации, тогда как параметры, переданные в строке запроса, более переменны и не влияют на какую часть вашего приложения направляется запрос. Хотя потенциально может также передавать набор параметров переменной длины через url:

GET somedomain.com/states/Virginia,California,Mississippi/

Хорошая книга для чтения в качестве учебника по этой теме "Restful Web Services" . Хотя я буду предупреждать вас о том, чтобы быть готовым пересмотреть некоторую избыточную информацию.

Ответ 4

Я думаю, это зависит. Один URL для одного ресурса. Если вы хотите получить этот ресурс несколько иначе, укажите строку запроса. Но для значения, которое будет поставлять другой ресурс, поместите его в путь.

Итак, в вашем примере значение переменной напрямую связано с возвращаемым ресурсом. Таким образом, это имеет больше смысла в пути.

Ответ 5

Первая вариация немного чище и позволяет вам резервировать параметры запроса для таких вещей, как порядок сортировки и страница, как в

http://www.rest.services.com/items/b?sort=ascending;page=6

Ответ 6

Это большой фундаментальный вопрос. Недавно я пришел к выводу, чтобы не использовать параметры пути. Они приводят к двусмысленному разрешению ресурсов. URL-адрес - это в основном "имя метода" части кода, работающей где-то на сервере. Я предпочитаю не смешивать имена переменных с именами методов. Название вашего метода, по-видимому, "клиент" (IMHO - это гнилое имя для метода, но люди REST любят этот шаблон). Параметр, который вы передаете этому методу, - это имя клиента. Параметр запроса хорошо работает для этого, и этот ресурс и значение параметра запроса могут быть даже кэшированы, если это необходимо.

Нет физического ресурса ИТ-клиентов. Вероятно, нет файла на диске в папке клиента, названной в честь клиента. Это веб-сервис, который выполняет какую-то транзакцию базы данных. "Ресурс" - это ваш сервис, а не клиент.

Эта навязчивая идея над REST и веб-глаголами напоминает мне о ранних днях объектно-ориентированного программирования, где мы пытались заковать наш код в виртуальные представления физических объектов. Затем мы поняли, что объекты обычно являются виртуальными концепциями в системе. OO по-прежнему полезно, когда вы делаете правильный путь. REST также полезен, если вы понимаете, что ресурсы RESTful являются сервисами, а не объектами.