It’s just data

Tilting at Windmills

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 | grep -i delete | wc -l

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.

Posted by bex at

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?

Posted by Sam Ruby at

Or to read Sam and Leonard’s excellent book distilling Roy’s Ph.D thesis for the commoner (like me). He’s probably too modest to plug it here, but I can honestly say it clarified many of my misconceptions and answered a lot of questions I had.

Posted by Christian Romney at


HOW TO WORK BETTER , must read. Monads are Plug-ins , and fun in ML too. belated happy birthday miss V! by chocolate monster mel How to Design Worlds: Imaginative Programming in DrScheme , by Matthias Felleisen, Robby Findler, Kathi Fisler, Matthew...

Excerpt from Anarchaia at

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.

Posted by Damien Katz at

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.

Posted by Sam Ruby at

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.

Posted by Damien Katz at

Sorry, I just realized my use of GETs is confusing because like you say, it doesn’t talk much about the request verb. What I mean is the paper talks about transferring data ("hypermedia") from server to client. But my question is does REST really only deal with that, and not have anything interesting to say about POST, or sending data from the client to the server?

Posted by Damien Katz at

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.

Posted by Sam Ruby at

  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.

Posted by Dare Obasanjo at

REST is the web, nothing more

I’m wrong. REST, as originally described, has nothing to do with POST PUT DELETE. If you look at the original paper (chapter 5), REST is simply a description of the web as it actually work as a distributed hypermedia browser......

Excerpt from Damien Katz at

REST is the web, nothing more

I’m wrong. REST, as originally described, has nothing to do with POST PUT DELETE. If you look at the original paper (chapter 5), REST is simply a description of the web as it actually work as a distributed hypermedia browser......

Excerpt from Damien Katz at

Add your comment