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).
> 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
That's a stupid idea. REST is built on two things: content types and resource location. The content types indicate the meaning and location of the resources, if the client does not understand the content-type, it can not do anything.
You can not "build a generic 'REST' client and point it to almost anything that is a 'REST API' and it will work", that makes no sense. Indeed, that's not what web browsers do: the driver of the API on a website is the user, not the browser.
> 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 :)
> That's a stupid idea. REST is built on two things: content types and resource location.
here is what my generic REST client looks like:
* HTTP[s]
* JSON
* Atom and RSS
* Caching layer
some controller login in between all of these. I inherit this to implement simple models and controllers in the client and just tell it which resources I want (like fields in a database)
how is that not a generic client?
for twitter I have classes called users and statuses, with each method defined. for google I have similar classes. this all took minutes for me to get working - I thought that was the entire point of REST?
read the original desertion, sec. 5.2.2 connectors:
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.
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.
PLEASE do not use the Wikipedia article as a citation. It's historically so full of misunderstandings that even Roy Felding himself has said it's nonsensical. This is a case where Wikipedia isn't quite "good enough" to let slip as a proper source for an argument.
Your arguments about nice looking URLs in fact have absolutely nothing to do with REST, except that REST says you must use your transport protocol according to its standards, where appropriate. It says nothing about how URLs should look. I you're talking about the HTTP spec, call it by its proper name please. We don't gain much from conflating different terms like this, it's just a source of confusion.
All query string parameters are used to identify the resource also. RFC 3986 states
"The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)."
There is absolutely no difference between path segments and query parameters from the perspective of resource identification.
A good rule of thumb here seems to be to put identity in the path and other things in the query string. For example, to search for items with property foo equal to 12 in the music collection known as bar, the url would be /music/bar?foo=12
