Хороший синтаксис URL для запроса GET с составным ключом

Question

Давайте возьмем следующий ресурс в моем REST API:

GET `http://api/v1/user/users/{id}`

В обычных условиях я бы использовал это так:

GET `http://api/v1/user/users/aabc`

Где aabc - идентификатор пользователя.

Однако бывают случаи, когда мне приходится проектировать API REST таким образом, чтобы некоторая дополнительная информация передавалась вместе с идентификатором.Например:

GET `http://api/v1/user/users/customer:1`

Где customer:1 обозначает, что я использую идентификатор из домена клиента для поиска пользователя, и этот идентификатор равен 1.

Теперь у меня есть сценарий, где идентификаторболее одного ключа (составной ключ).Например:

GET `http://api/v1/user/users/customer:1;type:agent`

Мой вопрос: в приведенном выше URL-адресе, что я должен использовать в качестве разделителя между customer:1 и type:agent?

Согласно https://www.ietf.org/rfc/rfc3986.txtЯ считаю, что точка с запятой не допускается.

Answer 1

Вместо того, чтобы пытаться создать общую структуру для доступа к записям через несколько ключей одновременно, я бы посоветовал попытаться подумать об этом в каждом конкретном случае.

Чтобы взять ваш пример,Одним из способов интерпретации этого является то, что у вас есть несколько клиентов, и каждый из этих клиентов может иметь несколько учетных записей.Естественной иерархией для этого может быть:

/customer/x/user/y

Часто такое элегантное решение может быть принято, которое не только решает проблему, но и документирует вашу модель данных таким образом, чтобы кто-то мог легко увидеть, что пользователипринадлежат клиентам через отношения 1-ко-многим.

Answer 2

Вы должны либо:

Использовать параметры: GET http://api/v1/user/users?customer=1

, либо использовать новый URL: GET http://api/v1/user/users/customer/1

Но использовать стандарты, такие как this

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