Re:Dudes, this is so not REST
by wahnfrieden on Tuesday March 15, 2011 @05:23PM
(#2329458)
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.
Then the RFC has defined a fairly useless standard. Wouldn't be the first time.
Re:Dudes, this is so not REST
by Robin_Message on Wednesday March 16, 2011 @10:43AM
(#2332196)
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
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.