Я думал, что одной из основных характеристик и причин использования веб-сервисов 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
Ну, а теперь есть некоторая неясность при первом взгляде. Соединенные Штаты - это идентификатор? Что ж, эту двусмысленность можно решить, сказав, что идентификатор представлен как \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. В частности, это видео, которое действительно тема здесь.
