Dudes, this is so not REST

Re:Dudes, this is so not REST by masklinn on Tuesday March 15, 2011 @03:00PM (#2328888)

Behold, the know-nothing.

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.

[ Parent | on HN ]

Re:Dudes, this is so not REST by johns on Tuesday March 15, 2011 @04:58PM (#2329358)

You could have defended your point without the name calling. You're just undermining your otherwise correct point with crap like that.

[ Parent | on HN ]

Re:Dudes, this is so not REST by swombat on Tuesday March 15, 2011 @03:47PM (#2329064)

See http://en.wikipedia.org/wiki/Representational_State_Transfer

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Dudes, this is so not REST by Darrel on Tuesday March 15, 2011 @05:04PM (#2329385)

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.

[ Parent | on HN ]

Re:Dudes, this is so not REST by swombat on Wednesday March 16, 2011 @05:12AM (#2331370)

Then the RFC has defined a fairly useless standard. Wouldn't be the first time.

[ Parent | on HN ]

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

[ Parent | on HN ]