What is the benefit of global resource URIs (i.e. addressability)?

Question

What is the benefit of referencing resources using globally-unique URIs (as REST does) versus using a proprietary id format?

For example:

1. http://host.com/student/5
2. http://host.com/student?id=5

In the first approach the entire URL is the ID. In the second approach only the 5 is the ID. What is the practical benefit of the first approach over the second?

Why does REST (seem to) go out of its way to advocate the first approach?

-- EDIT:

My question was confusing because it really asked two separate questions:

1. What is the benefit of addressibility?
2. What is the difference between the two URI forms seen above.

I've answered both questions below using my own post.

Answer 1

I will answer my own question:

1) Why are URIs important?

I'll quote from RESTful Web Services by Leonard Richardson and Sam Ruby (ISBN: 978-0-596-52926-0):

Consider a real URI that names a resource in the genre “directory of resources about jellyfish”: http://www.google.com/search?q=jellyfish. That jellyfish search is just as much a real URI as http://www.google.com. If HTTP wasn’t addressable, or if the Google search engine wasn’t an addressable web application, I wouldn’t be able to publish that URI in a book. I’d have to tell you: “Open a web connection to google.com, type ‘jellyfish’ in the search box, and click the ‘Google Search’ button.

This isn’t an academic worry. Until the mid-1990s, when ftp:// URIs became popular for describing files on FTP sites, people had to write things like: “Start an anonymous FTP session on ftp.example.com. Then change to directory pub/files/ and download file file.txt.” URIs made FTP as addressable as HTTP. Now people just write: “Download ftp:// ftp.example.com/pub/files/file.txt.” The steps are the same, but now they can be carried out by machine.

[...]

Addressability is one of the best things about web applications. It makes it easy for clients to use web sites in ways the original designers never imagined.

2) What is the benefit of addressibility?

It is far easier to follow server-provided URIs than construct them yourself. This is especially true as resource relationships become too complex to be expressed in simple rules. It's easier to code the logic once in the server than re-implement it in numerous clients.

The relationship between resources may change even though the individual resource URIs remain unchanged. For example, if Google Maps were to change the scale of their map tiles, clients that calculate relative tile positions would break.

3) What is the benefit of URIs over custom IDs?

Custom IDs identify a resource uniquely. URIs go a step further by telling you where to find it. This simplifies the client logic.

Answer 2

The main thing when i see uri's like that is a normal user would be able to remember that uri.

Us geeks are fine with question marks and get variables, but if someone remembers http://www.host.com/users/john instead of http://www.host.com/?view=users&name=john, then that is a huge benefit.

Answer 3

Search engine optimization mostly.

It also makes them easier to remember, and cleaner, more professional looking in my opinion.

Answer 4

The first is more aesthetically pleasing.

Technically there is no difference, but use the former when you can.

Answer 5

As Ólafur mentioned, The clarity of the former url is one benefit.

Another is implementation flexibility.

Let's say that student 5 changes infrequently. If you use the REST-style url you have the option of serving a static file instead of running code. In Rails it is common that the first request to students/5 would create a cached html file under your web root. That file is used to serve subsequent requests w/o touching the backend. Naturally, there's nothing rails specific about that approach.

The later url wouldn't allow for this. You can't have url variables (?, =) in the names of static pages.

Answer 6

Both URIs are valid from a REST perspective, however just realize that web caches treat the querystring parameters very differently.
If you want to use caching to your advantage then I suggest that you do not use a query string parameter to identify your resource.

Answer 7

I think it comes down to how closely you want to adhere to the principles of feng shui.