[Sidnicious]

I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this:

  /networks/
  /networks/girl_talk/
  /networks/girl_talk/tracks/
  /search?term=bass&sort=artist

He argued for URLs like this (note the pluralization):

  /networks/
  /network/girl_talk/
  /network/girl_talk/tracks/
  /search/bass/sort/artist/

My case boiled down to, “A URL represents the path to a resource. You should be able to remove any number of parts from the end of a URL and be left with a different, meaningful URL. In the case of search, the terms are options that describe what you want returned by the search, not resources.”

His case boiled down to, “A URL is a sentence. You should be able to read a URL as English and get a good idea of what it represents. In the case of search, adding more path components adds words to the sentence to make the search more specific.”

He pointed out (paraphrasing) that URLs are a language — and languages evolve. URLs as paths better embodies the RFC, but a new style of URL might be more meaningful on today’s (and tomorrow’s) web.

[glhaynes]

Slash-divided parts of URLs generally seem to me to describe a hierarchy, both because of the traditional structure of many URLs and slashes' traditional usage as a hierarchical path-delimiter. So I personally prefer your proposal because it makes a to-me clearer distinction between the resource that's being specified and the rendering attributes applied to the presentation of that resource. So it seems more obvious at a glance which parts of your URL could be removed/changed and what would happen and it just "feels" more right.

[gnaritas]

I'd say your friend has bad taste and shouldn't be allowed to design the URL structure of your site. Your style is better, but neither is more or less RESTful because REST doesn't say anything about pretty URL. URL's don't have to be hackable to be RESTful, but it's nice. URL's don't have to be pretty to be RESTful, but it's nice. You have better taste than your friend. Your search however, is more RESTful than his as all of your searches use the same URL. You understand what a resource is, he doesn't.

[icebraining]

An URL is just a name. /network/girl_talk is just as valid as /uwef9. HATEOAS means that clients shouldn't know a-priori of any URL except for the entry point.

In the search case, I think your coworker is wrong, since that would mean you have to construct URLs by 'hand', which violates HATEOAS. GET or POST parameters should be used to avoid that.

[pornel]

     /search/bass/sort/artist/

That doesn't look like a hierarchical resource. You probably don't list sort options under /search/bass/sort/, and even then /search/bass/sort/artist/ wouldn't be logical subset of that.

This URL looks more like a different view on /search/bass resource, so /search/bass?sort=artist is IMHO more appropriate.

[ericmoritz]

The standard is to use / for hierarchal data and URL params to alter the resource's content. For instance:

/search/ would be an empty search, and for the sake of argument let us say that it returns the entire collection.

/search/?query=bass

This would restrict the collection to return only records that contain the word "bass". Based on the way that URLs are defined, these are considered separate resources.

The same with this URL:

/search/?query=bass&page=10

This is a different resource than the previous. In this case, sometimes it feels like the page should be a member of the search collection. It's up to you whether you prefer a URL like this

/search/pages/10?query=bass

In my head that is incorrect because to me the query string manipulates the last item in the hierarchy which is "pages/10". So the order of operations would look like this:

1. Select the first page from the search collection 2. return only items on the first page that contain the word "bass"

[_ikke_]

I would say it would be a different (limited) representation of the same resource.

[colin_jack]

In HTTP resources are the things identified by the URL, so if you change the query parameters you are addressing a different resource.

[smiler]

Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it.

Developers will use either, just do it and provide documentation and be done with it

[kenjackson]

Exactly. REST is interesting, but understand why its interesting. If you're doing it because its a popular buzzword, that's just cargo cult.

It's good to know about REST so you can use it where it makes sense. But at the end of the day, doing what is right for your app trumps following any given methodology.

[icebraining]

But then it's important to document when you're breaking the constraints. Nowadays it's impossible to know if a web service is actually following REST or not because everything remotely similar gets the same label.

[espeed]

This is the same position Mark Nottingham (http://www.mnot.net/personal/) takes and expresses in his talk "Leveraging the Web for Services at Yahoo!"(http://www.infoq.com/presentations/services-without-soap-yah...).

However, Mark created a service called "Is It RESTful?" (http://isitrestful.com/) to deal with all the engineers asking him that question :)

[colin_jack]

> Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it.

REST doesn't really care about pretty URIs either, in fact one truism about REST is that people who spend a lot of time worrying about pretty URIs are probably missing the more important aspects of REST.

Oh and I agree with you, people can spend a long time coming up with pretty and hackable URIs and in my experience clients often just don't care (sometimes its worth the effort though).