REST идиома для подколлекции?

Мое понимание REST (по общему признанию, ограниченное почти страницей википедии) состоит в том, что идиома для GETing a коллекция — ../resource/, а элемент — ../resource/itemId.

Есть ли стандартная идиома для GETing для подколлекции? Например, если элементы в коллекции имеют какое-то переключение состояния (скажем, состояния A, B, C, D), и я хочу иметь возможность запрашивать элементы с состоянием B, существует ли стандартный/общий/лучший способ сделать это?

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

../resource/B

../resource/state/B

../resource?state=B

Какие плюсы/минусы в них вы видите?


person Carl    schedule 26.06.2010    source источник


Ответы (2)


Вы хотите использовать третий, кроме множественного числа (поскольку вы получаете более одного)

../resources?state=B

Потому что он точно описывает то, что вы хотите. Вы GET работаете с ресурсом в определенном состоянии.

../resource/B

Будет означать, что вы получаете определенный ресурс, однозначно идентифицируемый B

../resource/state/B

Указывает, что вы получаете ресурс state, принадлежащий resource, однозначно идентифицированный B.

Альтернативой, если вы имеете дело с конечным числом состояний, было бы сделать состояние ресурсом само по себе и сделать ресурс дочерним элементом этого состояния. Тогда у вас было бы

states/B/resources

person Jamie Wong    schedule 26.06.2010
comment
можно поподробнее о множественном числе? Кажется, что идиома ../resource/ для всех данных, ../resource/id для конкретного данного, но вы говорите, что более поздним должно быть ../resources/. - person Carl; 27.06.2010
comment
Я думаю, это вопрос предпочтений. Как реализовано в Ruby on Rails, все всегда во множественном числе. /resources будет списком всех ресурсов, а /resources/12 покажет ресурс с уникальным идентификатором 12. - person Jamie Wong; 27.06.2010

Ограничения REST на самом деле ничего не говорят о том, как вы называете ресурсы. REST просто говорит, что у ресурсов должно быть имя.

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

person Darrel Miller    schedule 26.06.2010