Craig
Craig

Reputation: 585

REST URI definition

I can't get comfortable with defining 'good REST' URIs. The scenario is an existing site with products for sale. You can view data in a number of views, drilling down a hierarchy, but basically cat1/cat/ products, or cat 2/cat3/products or any combination of categories 1 to 4. The other products view is based on a search.

How do you form the URI's?

products/??????

Upvotes: 1

Views: 2859

Answers (3)

Fenton
Fenton

Reputation: 250832

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 (with a 301 permanant redirect to your preferred resource).

Upvotes: 0

Mike
Mike

Reputation: 3352

You can use use a query string 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

Upvotes: 1

Vincent Marchetti
Vincent Marchetti

Reputation: 4908

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.

Upvotes: 1

Related Questions