Damien Katz: "The web is built on REST. Therefore REST is good" Bullshit
I’m not sure what the purpose is behind creating a strawman based on a caricature of what some people view as best practices and then proceeding to shoot it down.
Damien Katz: "The web is built on REST. Therefore REST is good" Bullshit
I’m not sure what the purpose is behind creating a strawman based on a caricature of what some people view as best practices and then proceeding to shoot it down.
RFC 2068 was published in June of 1999. Roy’s Dissertation was published in 2000.
$ curl -s http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm | grep -i delete | wc -l 0
Update: Leonard Richardson demonstrates the dogma-free approach to the subject that you will find in RESTful Web Services.
If this is a straw man, then both pro-REST and anti-REST people need to be told. I must say, I hear this same claim out of the mouth of EVERYBODY I know who uses REST. I don’t know who started the talking point, but it isn’t helping.
If a notable pro-REST geek authored a post on the “top ten mistakes REST fans believe,” it would probably help people move beyond the nonsense.
Told what? That Roy was one of the primary folks behind the HTTP spec? That HTTP predated his dissertation? That Roy’s Dissertation describes some of the characteristics that made HTTP and the web successful, and not the other way around?
Or perhaps the fact that there are a number of REST fans and critics alike who have never bothered to read chapter 5 of Roy’s Dissertation, but that doesn’t stop them from spouting nonsense?
If REST is essentially a description of how the web is built and the web is successful, then I think it is obvious that we don’t need to tell people to do things in a RESTful manner, they obviously already are as it applies to the visible web.
However, to encourage this architectural style in APIs simply because its so successful for the web. I think is wrongheaded. Use this style if it actually makes sense, otherwise it’s pointless to talk about how great it is unless you are actually building web-like things or you have client editable resources where REpresentational State Transfer actually makes sense. Otherwise, using HTTP POST as a simple RPC is just fine, and plenty of successful web sites are doing exactly that.
Damien, can you show me where in chapter 5 the word “RPC” is mentioned? How about “POST"? "GET” is mentioned once — as an example.
As long as the discussion stays firmly in the “I think I heard something that somebody else said that if taken to the extreme would be absurd” there is no point to having a conversation.
Sam that paper seems to simply describe how to do GET right. Is that all REST is, doing GETs properly?
Because then yes, that’s what the web is built on, a very standardized GET mechanism, (almost every browser can read and understand your resources and formats) and essentially unstandardized POST mechanism (only one target server in the world is supposed to understand what this POST means). But I really thought REST meant something more in practice. I think many people think that it means much more.
The paper is not about any one specific protocol. It is about a number of criteria that can be used to evaluate systems, and in particular it is about the tradeoffs between a number of possible constraints.
The paper doesn’t say anything specific about POST. It does suggest that uniform interfaces are one constraint that you can chose to either accept or trade off against. So, yes, one can tunnel everything over POST and still meet all of the other constraints of REST. One of the downsides of doing so it that such applications tend to be more brittle and tightly coupled than otherwise necessary.
If you are in a position where you control both ends of the wire (either by being the author of both ends, or by being in a position to impose or dictate an interface), then this constraint may not be overly important.
Damien,
I started writing a comment on Sam’s blog and it got too long so it is now a post at Explaining REST To Damien Katz
In general it seems somewhere along the line you got the impression that REST is about using four HTTP verbs instead of two when designing service end points. This is a significant misconception. Building a RESTful service is about understanding how the Web works, why it works that way and then keeping that in mind as you build your service for the Web.
Of course, there are practical reasons for deciding to use PUT/DELETE instead of POST which are also described in the linked post. Hopefully that elevates the conversation so we aren’t batting straw men back and forth.