REST API, переменная пути и параметр запроса - PullRequest
Новая
       14

REST API, переменная пути и параметр запроса

9 голосов
/ 27 марта 2012

Я сейчас пишу веб-сервис, предоставляющий доступ к некоторым ресурсам. Я пытаюсь следовать REST, но сталкиваюсь с проблемой, касающейся некоторых частей моего API.

У меня есть следующая моча:

  • / myservice / users / : получить всех пользователей
  • / myservice / users / {userId} : чтобы получить определенного пользователя
  • / myservice / badges / : получить все значки
  • / myservice / badges / {badgeId} : чтобы получить определенный значок

Теперь моя проблема в том, что мне нужно реализовать способ, чтобы получить всех пользователей, у которых есть определенный значок. Я могу считать, что это всего лишь фильтр, который я применяю в списке пользователей, отсюда следующий uri:

  • / MyService / пользователей / фильтр = знак: {badgeId}

Или я могу считать, что это всего лишь подресурс значка, отсюда и следующий код:

  • / MyService / значки / {badgeId} / пользователей /

Какой из них кажется обязательным для REST-совместимости?

Должен сказать, что я прочитал некоторые посты на эту тему, а именно: Стандарт покоя: Параметры пути или Параметры запроса , но, похоже, они не охватывают мою проблему.

Ответы [ 4 ]

5 голосов
/ 29 марта 2012

Если вы ищете RESTful, рассмотрите возможность использования HATEOAS (ужасная аббревиатура, но ключ к истинному RESTful).

Используя HATEOAS, ваше представление Badge может выглядеть примерно так: 

<badge>
  <id>1234</id>
  <name>Admin</name>
  <link rel = "/rel/users"
        href = "/myservice/users?badge=1234" />
  <link rel = "self"
        href = "/myservice/badges/1234" />
</badge>

Это позволяет вашим клиентам отсоединиться от схемы URI вашего сервера, поскольку они просто получают GET на любой другой ссылке / rel /ссылка для пользователей.Разумеется, вашему серверу все еще нужно определить схему URI внутри, но если в какой-то момент в будущем вы решите, что вам это не нужно, вы можете легко изменить его, не нарушая своих клиентов.Например, вы можете захотеть изменить схему URI на второй вариант, что приведет к изменению представления Badge на следующее: 

<badge>
  <id>1234</id>
  <name>Admin</name>
  <link rel = "/rel/users"
        href = "/myservice/badges/1234/users" />
  <link rel = "self"
        href = "/myservice/badges/1234" />
</badge>

Клиенты, использующие отношение ссылок / rel / users, не подвержены влияниюизменение URI.Это сводится к тому, что ... использует HATEOS, и схема URI на самом деле не имеет большого значения .

Приветствия!

0 голосов
/ 23 ноября 2018

Используйте строку запроса, например: 

/myservice/users/?badge=badgeId&genter=male&year__gt=18

Это более спокойно.

0 голосов
/ 21 ноября 2018

Я настоятельно рекомендую использовать строку запроса.

Привязка переменной пути не подходит. Переменная пути нарушает данные анализа журнала доступа Apache. Ни один инструмент анализа не поддерживает переменную пути.

Если ваша компания использует APM - дорогой инструмент, переменная пути видит те же функции, что и независимый API.

REST? ХОРОШО. Но привязка должна использовать строку запроса.

0 голосов
/ 27 марта 2012

Я предпочитаю /myservice/users/?filter=badge:{badgeId}, и я думаю, что больше API используют этот формат.

...