You should disclaim that these URLs could just as well be
* /rdio?q=1&s=63
* /rdio?q=1&s=63-8
* /rdio/4E7?q=1
* /rdio/4E63?q=1
and still be part of a RESTful API.
/rdio/api/1/artist/1/tracks/2
/rdio?api=1&artist=1&tracks=2
Does it change how caching might work?
/rdio/api/1/artist/1/tracks/2/artist/1
I just did a quick check and Django, for example, will just take the second of any duplicated GET params.
the idea is that you can build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work, in the same way we can now with web browsers
a REST client will never figure out /api/1/ - which is why resources go in the path and query parameters go in as, well, query parameters :)
from the server side you are right that modern front controllers and routing can make it all the same (heck, I can route resources to different subdomains, if I want), but a proxy does not know what the front controller logic is (ie. working backwards to what part is what).
Also, I believe safari will ignore your caching/expires headers if you use GET params.
Nice urls with http verbs but no hateos is what most "REST" APIs are though.
Sorry sir, I'm not wrong, those would be perfectly valid as part of a REST service, including as alternatives to tptacek's description. Readability of the URLs has nothing at all to do with RESTfullness.
The only thing REST says about the data transmitted (the URL in this case) is that it's the container for the application's state, and most interpretations of this is that the URL is entirely opaque. And indeed, Fielding has suggested/explained this several times.
Those are not REST because they are not resource-based.
Correct REST:
http://blah.com/widget/:id - GET, PUT, POST, DELETE
How does that fit with your /rdio/4E7?q=1 ? Where's the resource? What is the id? What is q anyway?
You can pass parameters with a ? in REST... for example, you might do
GET http://blah.com/resource/123?format=xml
But there's still a clearly identified resource which the GET is performed on.
Sure, technically, by stretching things a bit, you could claim that /rdio?q=1&s=63-8 is a REST GET request for resource id "63-8".
And, technically, you'd be right, much like technically, this is valid C: http://stackoverflow.com/questions/18642/what-is-the-most-un...
But just because it's valid doesn't mean it's in any way good. Those are horrible examples. So no, those URLs could not "just as well" be those nasty examples you give. They could, much more poorly, be those examples, and still be technically valid. By the same reasoning, "Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" is just as good english as Shakespeare.