REST маршрутизация - объекты с несколькими уникальными параметрами

Question

Я прочитал несколько руководств по оптимальной маршрутизации REST, но ни один из них не смог ответить, как работать с объектами, которые имеют больше уникальных параметров, чем просто ID.

Так, например, я могу иметь ID и Код (оба уникальны ) для пользователя USER.

Простое получение по ID может выглядеть так:

/users/{id}

и получите по коду

/users/{code}

а что если ID и CODE оба являются целыми числами?

Я могу создать маршрут с фильтром строки запроса, например:

/users?code=123

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

/users?firstName=abcd

Так, каков наилучший способ обработки маршрутов для подобных объектов?

Answer 1

Имейте в виду, что REST не заботится о том, какие соглашения об орфографии вы используете для своих идентификаторов.Либо два URI одинаковы, и в этом случае клиент будет предполагать, что они ссылаются на один и тот же ресурс, либо два URI будут разными, и в этом случае клиент будет предполагать, что они ссылаются на разные ресурсы.

/users/{id}
/users/{code}

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

Поскольку целое число неоднозначно, вам нужно провести различие в URI в другом месте.REST не особенно заботится о том, как вы это делаете, если только идентификаторы соответствуют RFC 3986 .

/ebc8a29b-76a5-4f40-b37a-2d40eab9283d/{id}
/9193590d-fc47-4107-a160-e344b9cedb5c/{code}

Это вполне удовлетворительное решение в отношении REST.

/usersById/{id}
/usersByCode/{code}

Это также вполне удовлетворительно и, возможно, более легко употребляется людьми.

/users/id={id}
/users/code={code}

Еще один удовлетворительный пример;который дает вам удобочитаемость и общий сегмент пути /users, что может быть удобно, если вы хотите, чтобы относительные ссылки были встроены в представление.

Параметры матрицы - это часто используемый термин, который охватывает числоразличных способов встраивания информации в сегмент пути;есть разумная надежда на то, что если вы используете стандартную / стороннюю библиотеку для анализа вашего URI, то некоторые или все эти соглашения будут поддерживаться.

Answer 2

Если Id и Code не имеют одинаковых значений, я бы предпочел этот стиль."/ пользователей / {idOrCode}".Я могу написать свой запрос следующим образом: где (x => x.Id == id || x.code == idOrCode)