Стандарт отдыха: параметры Пути или параметры Запроса
Я создаю новый сервис REST.
Что является стандартом для передающих параметров к сервисам REST. От различных реализаций REST в Java можно настроить параметры как часть пути или как параметры запроса. Например,
Параметры пути http://www.rest.services.com/item/b
Параметры запроса http://www.rest.services.com/get?item=b
Делает любой знает что преимущества/недостатки для каждого метода передающих параметров. Кажется, что передача параметров как часть пути, кажется, совпадает лучше с понятием остальных протокол. Таким образом, единственное местоположение показывает уникальный ответ, корректный?
4 ответа
Пути обычно кэшируются, параметры - нет, как правило.
Итак...
GET /customers/bob
vs
GET /customers?name=bob
Первый с большей вероятностью будет кэширован (при условии правильных заголовков и т.д.), в то время как последний, скорее всего, не будет кэширован.
Ваш второй пример «параметров запроса» неверен, потому что «get» включен как часть пути. GET - это тип запроса, он не должен быть частью пути.
Существует 4 основных типа запросов:
GET PUT POST DELETE
GET-запросы всегда должны быть выполнены без какой-либо информации в теле запроса. Кроме того, запросы GET должны быть «безопасными», что означает, что запросом не изменяются никакие важные данные.
Помимо упомянутой выше проблемы кеширования, параметры в URL-пути, как правило, требуются и / или ожидаются, потому что они также являются частью вашей маршрутизации, тогда как параметры, передаваемые в строке запроса, более изменчивы и не влияют на то, какая часть вашего приложения, куда направляется запрос. Хотя потенциально может также передавать через URL-адрес набор параметров переменной длины:
GET somedomain.com/states/Virginia,California,Mississippi/
Хорошая книга для начинающих по этой теме - это «Restful Web Services» . Хотя я предупреждаю вас, чтобы вы были готовы просмотреть некоторую избыточную информацию.
Я думаю, это зависит от обстоятельств. Один URL для одного ресурса. Если вы хотите получить этот ресурс немного по-другому, дайте ему строку запроса. Но для ценности, которая доставляет другой ресурс, поместите его в путь.
Итак, в вашем примере значение переменной напрямую связано с возвращаемым ресурсом. Так что путь имеет больше смысла.
Первый вариант немного чище и позволяет зарезервировать параметры запроса для таких вещей, как порядок сортировки и страница, как в
http://www.rest.services.com/items/b?sort=ascending;page=6