Common REST Mistakes
prescod.net
Common REST Mistakes
1–10 of 41 posts
Re: Common REST Mistakes
#2What REST actually is, is not explained on this page. More information can be found here: http://en.wikipedia.org/wiki/Representational_State_Transfer
Re: Common REST Mistakes
#3Point 6 (Sessions are Irrelevant) is really tricky. Fielding says much the same about sessions as this article but there's a lot of room for clarification.
Re: Common REST Mistakes
#4Point 6 (Sessions are irrelevant) is where REST really falls down as a way of explaining the success or practical operation of the web.
Re: Common REST Mistakes
#5Point 3 is phrased well in the title, but I'm kind of annoyed at the implication that you should intentionally obscure your URLs. I can see why he makes that point, and I see the benefit, but I also like URLs that make sense when I'm cutting and pasting.
I have a much easier time finding a cut-and-paste error from email in http://bob.com/posts/37/comments/79 than in http://bob.com/postthing/1f724c302a3b69ef9327313adb269a8d, even if the latter is convenient when the site later restructures things or adds a server.
Re: Common REST Mistakes
#6Several of these points are highly prescriptive without offering any motivation for the advice.
For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website.
The whole list presupposes a familiarity with REST theory and jargon. And the assertion that 'sessions are irrelevant' instantly raises my suspicions about the author's relationship with reality.
Re: Common REST Mistakes
#7Point 6 (Sessions are Irrelevant) is really tricky. Fielding says much the same about sessions as this article but there's a lot of room for clarification. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
My take on "sessions are irrelevant" is that you don't start and close a session. You start by creating a resource: itenerary, document, submission or whatever you call it. You do that by POST-ing to the list of such resources and you edit it (PUT) until you're done. You could always come back to it (GET) and edit some more (PUT). Or you could delete it (DELETE).
Of course, there can be authentication and authorization but, really, there's no need for a session since you have to do those two on each http request anyway.
Re: Common REST Mistakes
#8I believe #3 is actually a cornerstone of modern Ruby on Rails usage :-)
Re: Common REST Mistakes
#9Several of these points are highly prescriptive without offering any motivation for the advice. For example, "your public API should not depend on the structure of your URIs. Instead there would typically be a single XML file that points to the components of your service." It's difficult to understand this kind of point without an example in hand - preferably an example taken from an actual website. The whole list pr…
I agree. A lot of the more pedantic REST advocates seem to use this kind of thinking, such as implying that we shouldn't use descriptive URIs because the client or programmer shouldn't need to understand how the URIs are structured. If that's the case, surely we could break REST convention as much as we want and just make the programmer or client go along with it.
I think when most normal people say REST, they simply mean some sort of vague messages-over-HTTP metaformat that doesn't necessarily enforce odd restrictions about POST vs. PUT, is somewhat self-documenting and easy to work with due to the limited scope of the medium, etc.
Re: Common REST Mistakes
#10Since a number of people have mentioned point #6 (Sessions are irrelevant), I have a question: Can anyone point to a concrete, more detailed discussion of how to do authentication and authorization in a RESTful manner?
I may be missing something very obvious, but I just don't see how this should/can/might look. (Just to be explicit, I'm not trolling. I'm confused.)