RESTful URIs, Just Eye Candy?

If I were to implement a search engine, should I expose a search for ipod as

http://tinou.com/search/ipod     or     http://tinou.com/search?query=ipod

That was the basic question I had for my colleagues today.  After some discussion about URIs, resources and REST, and some links to W3C specifications, I still feel unsatisfied.  General statements were made, like canonical resources allow for caching and flexibility, but nothing concrete was offered.  There was no,

Technorati uses /search/ipod and they saw a 30% performance increase from caching!

So I'll ask the same question to the larger community:  What is the real, actual benefit of a RESTful (*) URI as opposed to one that uses ROP (regular old parameters).  Is it purely aesthetic, or are there tangible technical and design benefits to not having that query parameter in the URI?

I will readily admit that for some things, pretty URIs with no parameters are great.  Compare

www.facebook.com/profile.php?id=689851030
www.facebook.com/profile/tinoubao. 

But what about this most basic case of a simple search?

In some ways, I think having the parameter is clearer, because I know exactly what the query term is.  Imagine if someone from China was doing a search,

http://tinou.com/search/%E6%B1%89%E5%AD%97
http://tinou.com/search?query=%E6%B1%89%E5%AD%97

You may not know Chinese, but you know query is %E6%B1%89%E5%AD%97 in the second URI.  Silly example, maybe... 

But what about how HTML forms only support parameters and not resources.  A simple search HTML form would be

<form action="/search">

<input type="text" name="query"/>
<input type="text" name="lang"/>

<input type="submit" name="submit" value="search"/>

</form>

The resulting request might be /search?query=ipod&lang=en.  Easy enough.  But if I was RESTful, I would need to convert this to action="/search/ipod" with Javascript before making the request, complicating the client.  I could, of course, not use Javascript and do the canonicalization on the server,

/search?query=ipod&lang=en     into   /search/ipod?lang=en

But this complicates the server logic.  And here's the thing, at the end of the day, when my search code does the real work of searching for ipod in English, it will inevitably work with parameters named query and lang, with values ipod and en, respectively .

So after the server translates the parameters into a RESTful URI we translate it back into parameters to pass to our worker code.  Seems awfully wasteful, since we already had the parameters from the start, unless there's something that this style of URIs gain us that I'm missing.

Closing thought: this is not a debate about REST versus SOAP versus XML-RPC.

edit:

* To clarify, by RESTful I just mean the URI style that you typically see in REST discussions, examples, etc.  Did not mean to say that one URI is REST and another is not.  I'm just talking about the style. 

Comments

[KiLVaiDeN]

Hi,

One simple advantage of the Rest URIs, is referencing.
Another one, is "human readable".

Simply put, I think that the classic urls are out of date nowadays, because of all those community driven bookmarking solutions. It's must easier and natural, to have an url describe exactly what it's referencing, rather than having parameters mixed with a part of url.

but really, the main advantage, is referencing :)

Cheers
K

[tinou]

I'm not sure what you mean by referencing. All URIs are referenceable.

I won't argue about human readable. tinou.com/cameras/slr/nikon/D200 is better than tinou.com?type=slr&manufacturer=nikon&model=D200.

But that falls under aesthetic. And in this simple search example, I'm not really sure if it's that more human readable, if at all.

[Anonymous coward]

About the only non-aesthetic difference I can think of would be with respect to search engine optimisation, but that's a black enough art that it's hard to make sweeping generalisations.

I personally wouldn't discount the value of aesthetic URLs though - if you've ever been forced to work with a web technology that didn't support them (portals and web CMSes are notorious for this kind of thing) then you'd have a deep appreciation for them.

[brokenshard]

"I won't argue about human readable. tinou.com/cameras/slr/nikon/D200 is better than tinou.com?type=slr&manufacturer=nikon&model=D200."

I dont agree with that. I think the url with the parameters is more readable. simply because the restful uri does not say what is slr and what is nikon, while the parametric url does specify it as type and manufacturer.

maybe. :)

[nikosk]

Actually the URI "tinou.com?type=slr&manufacturer=nikon&model=D200" would translate into tinou.com/type/slr/manufacturer/nikon/model/D200"
because even in REST URIs you must have must have key/value pairs unless the URI references a static resource (i.e. a blog post).

Anyway, the main advantage is that URI keywords gives you an extra boost in Google rankings and in addition helps your users know what the URI references.

For reference you can take a look at a web app I developed @ http://www.roditikes-aggelies.gr (it's in greek but I think you can still see how the URIs work). BTW the translation code (REST to params to REST again) is about 20 lines of code.

[raveman]

cant you just use POST and be happy?

[Jorge]

Both URIs presented as options are RESTful, no one is more RESTful than the other since one of the principles of the web (and thus of REST) is that of URI opacity.

What is important from a REST point of view is that the URI points to a resource, that it can be operated using an standard set of verbs (in this case it's easy since it's only GET) and that it returns a representation as a result (preferably with links to other resources aka application states).

REST is very abstract, so let's examine a more concrete RESTful architecture, such as the Resource Oriented Architecture (the one introduced in the RESTful Web Services book). Regarding your question they recommend:
- Put information in the path when the values are a limited set
- Put information in query parameters when the potential values are infinite (such as in a query).

So one of the most known RESTful architectures actually recommends that you use:
http://tinou.com/search?query=ipod

Although, as I said at the beginning, both are RESTful.

[Chase Saunders]

I think the examples present a bit of a straw man... it's not really about "http://tinou.com/search/ipod" or "http://tinou.com/search?query=ipod". It's about taking control of URL's versus not. So tinou.com/search/ipod versus

http://tinou.com/search?query=iPod&distId=23948&filter=whatever&lan=en...

We recently implemented an app for the Navy, used mainly for filtering and reading data, in which the filter critera are all clearly readable in the Query string. If you are working on ship D155 and you want Engineering stuff, for example, you'd get something akin to this:

http://somesite.com/somepage.aspx?ship=D155&system=Engineering

We had to do a hell of a lot of work to pull this off, despite that we have visible parameters it's not what would have naturally arisen if we used POSTs or let .NET do it's thing or whatever (esp. with a lot of AJAX calls).

Our substantial effor was very clearly rewarded though: we didn't have to implement saved or shared searches. If you want to save a search, you add a Bookmark. If you want to share a search, you mail your buddy a link. We had explained all this on paper, but when the client finally "got" it they went through the roof. They're emailing links like crazy and I'd have to guess saving about 12,000 trees per day.

We're seeing power users now type in links directly, and tweak existing links, and I view that as part of the same payoff.

Chase

[tinou]

thanks for the comments. i should clarify that i didn't mean to imply that having query parameters wasn't "REST" -- but i guess with all the REST examples you typically see hierarchical paths being used, so I think many, including myself, just call this type of URIs "RESTful" This is technically incorrect, as you pointed out, but I don't have a better short word to describe this URI style.

[Brandon Smith]

"""...but I don't have a better short word to describe this URI style."""

How about 'Cool URIs'.

http://www.w3.org/Provider/Style/URI