REST idiom for a sub-collection?

Question

My understanding of REST (admittedly limited to pretty much the wikipedia page) is that idiom for GETing a collection is ../resource/ and an item is ../resource/itemId.

Is there a standard idiom for GETing for a sub-collection? For example, if the items in the collection have some state toggle (say states A, B, C, D), and I want to be able to ask for items with state B, is there a standard/common/best-practice way to do that?

If not, I'm currently fiddling with the following syntax options:

../resource/B

../resource/state/B

../resource?state=B

What pros/cons of those do you see?

Answer 1

You want to use the third one there, except plural (since you're getting more than one)

../resources?state=B

Because it accurately describe what you want. You're GETing a resource with a specific state.

../resource/B

Would indicate you're getting a specific resource uniquely identified by B

../resource/state/B

Would indicate you're getting a resource state, belonging to resource, uniquely identified by B.

An alternative if you're dealing with a finite number of states would be to make state a resource by itself and make the resource a child of that state. Then you would have

states/B/resources

Answer 2

According to the internet. THe most RESTful would be:

../resource?state=B

Any filtering is done through the query string.

Answer 3

The REST constraints actually say nothing about how you name resources. REST just says resources should have a name.

Having said that, Jamie's answer is probably the most obvious way of doing it. You can compare naming URLs to naming procedures, there is no right and wrong way to do it, just some names are more obvious than others.