REST URL для списков

Question

Допустим, у меня есть метод, который возвращает список клиентов, а в качестве входных данных используется список состояний и список размеров, что-то вроде

возврат клиентов, для которых указано состояние (Нью-Йорк, Калифорния, Техас) и размер (маленький, средний)

Какой лучший RESTFul URL я должен использовать? Проблема в том, что это запрос и не указывает на конкретный «ресурс». Вот некоторые варианты, которые я обдумываю.

1. somesite.com / клиенты? Штат = Нью-Йорк, Калифорния, Техас и размер = маленький, средний (старый стиль)
2. somesite.com / клиентов / штат / штат Нью-Йорк, Калифорния, Техас / размер / малый, средний
3. somesite.com / клиентов / состояние = NY, CA, TX / размер = малый, средний
4. somesite.com / клиентов / штат (Нью-Йорк, Калифорния, Техас) / размер (маленький, средний)

Answer 1

Вариант 1 - параметры запроса предназначены именно для этого. Параметры для вашего запроса.

Вас интересует список клиентов, поэтому последняя "папка" должна быть "/ Customers". Тот факт, что вам нужно подмножество этих и то, что это подмножество является вариантом, зависящим от входных данных, и в комбинации приводит к тому, что параметры запроса действуют как фильтры. (Ничто другое не имеет смысла, как вы видите, будучи вынужденным задать вопрос).

Реальный вопрос, который у вас есть, заключается в том, будут ли параметры включаться или исключаться по умолчанию (т.е. И или ИЛИ). Этот вопрос уже задавался здесь, если я смогу найти его ...

Answer 2

Я думаю, что # 1 (somesite.com/customers?state=NY,CA,TX&size=small,medium) - лучший из всех. Клиентами являются ресурсы, а строка запроса просто накладывает ограничения на запрашиваемые ресурсы.

Answer 3

Лично я бы использовал 4-й подход, но со знаком «+» вместо скобок:

somesite.com/customers/NY+CA+TX/small+medium

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

Answer 4

Как ни крути, соглашения об именах URI не имеют ничего общего с REST. Фактически, если вы определяете способ создания URI вне приложения как часть вашего API, вы нарушаете ограничение REST. Смотри: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven