Я думал, что одной из основных характеристик и причин использования веб-служб REST было использование параметров пути, а не параметров запроса. Но многие общедоступные веб-службы REST используют параметры запроса.
Я ошибаюсь, думая, что параметры запроса не должны использоваться в веб-службах REST? Есть ли рекомендация или правило об отсутствии параметров запроса в веб-службах REST?
Строка запроса все еще может использоваться в веб-службах REST только не так, как обычно.
Вы должны подумать о URL-адресе в качестве ключа к ресурсу. URL-адрес является уникальным идентификатором ресурса. Например
http://example.com/products/123 -- where 123 is the id of the products.
Доступ к /products приведет к возврату полного списка продуктов. Добавление идентификатора приведет к возврату определенного продукта.
Что делать, если вы хотите заказать продукт определенным образом? Некоторые скажут
http://example.com/products/united-states
Хорошо, теперь на первый взгляд есть некоторая двусмысленность. Является ли единое целое идентификатором? Ну, эту двусмысленность можно решить, сказав, что id представлен как \d+. Правильно.
Итак, наши первые параметры, которые сделаны из слов, являются страной.
Теперь скажем, мы хотим добавить больше фильтров, попробовать и добавить больше слэшей.
http://example.com/products/united-states/home/asc
Но я не хочу только продукты Соединенных Штатов! Но по-прежнему нужны домашние продукты.
http://example.com/products/home/asc
Подождите... домой страна? Теперь я не уверен, это немного двусмысленно... И что, если я хочу добавить еще один фильтр завтра? Что мне делать... добавьте больше слэшей?
URL-адрес становится загроможденным и заполнен неоднозначными параметрами, которые были необязательными сначала и которые становятся обязательными из-за двусмысленности.
Правильным способом для меня было бы использовать строку запроса для конкретной информации о запросе. Поскольку я могу сортировать запрос любым способом, я хочу, это все тот же запрос. Я запрашиваю продукты.
Таким образом, форма должна выглядеть как
http://example.com/products -- all products
http://example.com/products/{id} -- specific one
http://example.com/products/?country=united-sites -- filtered
Таким образом вы можете добавлять новые фильтры в любое удобное для вас время и сохранять четкие URL-адреса и никогда не сломаться, даже если вы меняете фильтры.
Если вам нужна дополнительная информация, я действительно рекомендую вам посмотреть эту конференцию Дэвид Зюлке, парень, работающий на Symfony фреймворк. Он рассказывает о многих вещах веб-сервисов REST, но также говорит о URL-адресах и о том, как их создавать (главным образом, от 16 до 30 минут).
Вы также можете посмотреть сайт apigee. У них есть много видео (и книг) о REST. Более конкретно это видео, которое действительно по теме здесь.