REST URI definition

Question

Hi, I'm reading REST and nearly ready to try it but I can't get comfortable with a coupel of things. The first is to do with defining the URI's.
The scenario is an existing site with products for sale. You can view data in a number of views, driling down a hierarchy, but basically cat1/cat/ products, or cat 2/cat3/products or anycombination of categories 1 to 4. The other products view is based on a search.
How do you form the URI's?

products/??????

Any advice? I can't settle on an answer I'm happy with.

Thanks, Craig

Answer 1

Yes - the problem here is that you don't have a unique ID for the resource because:

products/cat1/cat4

Is actually the same page as

products/cat4/cat1

(Presumably a view of everything tagged with cat1 and cat4, or all matches from cat1 and cat4)

If your categories where organised into a hierarchy you would know that "cat6" is a child of "cat1", for example.

So your two options would be

1) Enforce a natural order for the categories

or

2) Have two different URI's essentially pointing to the same resource.

Answer 2

Use a query/search part in your URI:

/products?categories=german,adult,foo,bar

In order to avoid multiple URIs you could enforce some logic like alphabetical ordering of categories on the server side so a request to the above URI would actually redirect via a 301 Moved Permanently response to:

/products?categories=adult,bar,foo,german

For that above query part pattern to work in browsers you will have to use javascript to generate the query from any html forms - you could, alternatively, do it like this if you wanted to avoid that particular problem:

/products?cat1=adult&cat2=bar&cat3=foo&cat4=german

Answer 3

Having designed a site that follows the principles of the REST architecture, my advice is to base your decision on your URI structure solely on your server design, that is how your server will parse an incoming URI and deliver the corresponding resource.

One principle of REST design (as I see it) is that your users/clients will NEVER have to form a URL to find a resource, they will instead read some hypertext (i.e. HTML) which describes resources, identify what they want, and get the appropriate link from the hypertext (for example, in HTML, the href attribute of the tag holds the URL, which could just as well be a random string of characters.

Again, in my opinion, if your application requires that a user/client be able to perform searches for arbitrarily named categories, it's probably not suitable to have a RESTfully designed interface.