21–30 of 41 posts
I believe #3 is actually a cornerstone of modern Ruby on Rails usage :-)
I believe #3 is actually a cornerstone of modern Ruby on Rails usage :-)
I have not read Roy Fielding's dissertation, and so I am speaking out of partial ignorance. But isn't most of this the opposite of what REST is supposed to be? URLs aren't supposed to represent resources? Whahh?
I believe #3 is actually a cornerstone of modern Ruby on Rails usage :-)
I have not read Roy Fielding's dissertation, and so I am speaking out of partial ignorance. But isn't most of this the opposite of what REST is supposed to be? URLs aren't supposed to represent resources? Whahh?
Repeat after me: Hypertext. Is. The. Engine. Of. Application. State.
URL strings should be completely opaque -- you should be finding link to new resources in other resources, not constructing them yourself (query strings added to found resources are permitted).
The whole "meaningful URL" thing is a strong signal of False REST, and it infects the Rails ecosystem pervasively. REST has nothing to do with your oh-so-clever request routing rules.
Since 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.)
He lost me at 'use PUT and DELETE'. There's a whole range of clients (eg most browser's XMLHttpRequests, Flash) that don't support anything but GET and POST.
But yes - Flash can only use POST and GET (or maybe only POST? It's been quite a long time since I used Action script)
REST has always felt a little bit dirty to me; an improper commingling of what should be two different layers. To me, using aspects of the HTTP protocol to have meaning for a higher level service is a bit like using aspects of the TCP protocol as part of the HTTP definition, where in a more ideal setup they should be independent, but layered on top of one another. Almost all of the REST mistakes mentioned in this art…
I think you might be wrong about the 'underlying protocol'. HTTP is an application layer protocol. If something feels dirty it is to put another protocol on top of it especially if it doesn't add value. With REST, you are not adding more special meaning than the HTTP methods. Using those methods according to the spec is all there is to it. If that's enough to do your business, why add more to it? Things should be sim…
He lost me at 'use PUT and DELETE'. There's a whole range of clients (eg most browser's XMLHttpRequests, Flash) that don't support anything but GET and POST.
Not true, XHR allows to use DELETE and PUT without any problems. But yes - Flash can only use POST and GET (or maybe only POST? It's been quite a long time since I used Action script)
Earlier quoted context omitted.
I have not read Roy Fielding's dissertation, and so I am speaking out of partial ignorance. But isn't most of this the opposite of what REST is supposed to be? URLs aren't supposed to represent resources? Whahh?
The contents of URL strings are not supposed to represent resources -- If a client of your "REST API" needs to concatenate strings together to form new URLs based on an out-of-band 'specification', YOU'RE DOING IT WRONG Repeat after me: Hypertext. Is. The. Engine. Of. Application. State. URL strings should be completely opaque -- you should be finding link to new resources in other resources, not constructing them yo…
Several 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…
By "sessions are irrelevant", he basically means "don't recreate circuit switching on top of your packet-switched TCP/IP connection." Each HTTP request should carry with it all the state required to do what it needs to do (including state stored in cookies et all); it shouldn't be dependant on what has come before or what will come after it.
I am old enough to remember the first time the session pattern was used in a web framework, I remember cringing then just as I do now when I see it used.