Damien Katz

Hey Damien I think you're diving too deep. You're right it's the URLs and basic HTTP request - the heck with the verb. But compared to SOAP or whatever it's basically just the raw web.

Do you dare claim the lining of the Emperor's cloak is not the finest silk, or that the trim is not the most sumptuous ermine?

"The argument that REST is great because it provides standardized caching support..."

I think this is a massive oversimplification.

HTTP is _not_ a transport protocol, but a transfer protocol.

I agree that just focusing on the uniform VERBS is too narrow, but there are three things the Web is built on:
1. URI
2. HTTP
3. HTML

That last one provides the hypermedia-ness and allows new links and transitions to be discovered opportunistically by smarter clients (think microformats).

From Roy's thesis, section 5.3.3:
"The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations."

This is a different style of integration than RPC. it provides some distinct benefits especially to evolution of independent systems and serendipitous, opportunistic reuse.

I love living in the modern age.

It's so refreshing to have moved from religious fights based on the Bible to religious fights based on RFCs.

I'm not too fond of rails making active resource REST by default. And will completely agree with Damien here.

REST for a datasource/database access makes perfect sense. You don't need REST on all CRUD based sites. Many don't even flow properly if you use REST.

You don't have to use REST if you don't need REST.

And don't be stupid, don't use GET for non-idempotent calls. It's not that difficult. You can use POST for everything else, it's okay, the internet won't bite.

I absolutely agree. I have been saying this for a long time. Basically, the http spec was designed long before the idea of dynamic web applications. Trying to say that REST is how the http was intended to be used, is fine and great and all, but does not really apply to how we are using http today. Trying to build your application with only four "verbs" is terrible, you have to build so much cruft just to get everything on your object to work with the four verbs, not to mention trying to build a user interface on top of it.

The obsession with verbs is ... an obsession with verbs. It's no more REST then the obsession with naming elements is XML, or the obsession with table name conventions is database management.

REST is mostly links and forms. If you do all your state transfer over POST, it's still RESTful.

It's better to do verbs right and get advantage of HTTP, but if you find yourself bikeshedding over them, you've lost the big picture.

Wow. Why is this so important?

Anyway, the web is not built on REST. REST happens to be a relative good way to describe some of the good aspects of the web.

So, the accusation has been made that REST is just a bunch of apparatus built up around "Doing HTTP right" to make it intellectually respectable.

I personally think that there is more to it than that, but whatever; "Doing HTTP right" is a big deal in the big picture, and if that's all we get out of the current REST fashion craze, I'm OK with that.

The actual cant is that REST was the principle used in designing http (objects), http has worked pretty well for the web, so maybe your interface should be use those principles too. Additionally all the other stuff on the web is based on http, therefore you can get all this nice caching, redirecting, expires, and etags functionality for free.

For what came first, check out http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_2

The PUT and DELETE fetishism confuses me too. But does seem like most good interfaces define them any way, they just do it in post. So the concept is pretty accurate.

To me most useful guideline is that if you are putting in complexity, put it in the resource instead of the verbs. So the resource can be complex like /recent-pictures-from-friends. But you shouldn't be having a conversation like 1) init my friend pictures, 2) take those and order by date descending, 3) give me 10 off the top. It's kind of attractive to think like this because then someone can reuse your 3) function and you are reusing that very function in your own code too. But now there's an ugly state blob on your server, and clients have some understanding of that state on their side too. ...blah blah, you've heard the rest of this before...

So to me it's GET and POST, and then in the POST you say often end up with do=PUT, or do=DELETE. You try not to say do=intiateStep3.

And it's not that you can't. EDI, RPC, JRMI, and SOAP employ lots of folks and their stuff works. It's that it's harder for everyone to use and that's most important.

I thought there were some good comments in response to your previous post; just from the top 5 or so: colin, john, shahzad. They pretty much addressed you head on. But you decided to pick one statement from whereever and call bullshit. You're not really arguing in any constructive sense anymore. This is really like the cable news talking heads style of debate -- wait for someone to make a silly statement, ignore everything else, call bullshit as loud as you can, wave hands wildly and move on. Lame.

Since you asked, http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

I don't get it - is REST supposed to be the way to communicate between the webserver and browser, or between the webserver and database? The features that make the design of the web pretty good for the former (tolerance for errors and inconsistency) make it not so good for the latter.

Web servers may be configured/coded to have different permissions based on request method and user role. Assume an application where guests may POST comments but not PUT to edit them. Members may POST comments, and PUT to edit them, but not DELETE them. Only Administrators may DELETE comments. The URI does not vary. That's as good a reason as any not to tunnel everything through POST, assuming HTTP authentication is used.

@Otto:
Either. Speaking only of XML DBs, most have a REST interface out-of-the-box, as the URI path and the DB's query path are identical.

The web has shown that POST & GET make sense but PUT and DELETE aren't necessary.

> The web has shown that POST & GET make sense
> but PUT and DELETE aren't necessary.

Not at all. Most POSTs are used to model missing PUTs and DELETEs. Imagine a RESTful Web. There would be no need for FTP upload tools for normal users. The web would be like a Wiki with access control, which would be way cooler. As the web is based on resources, REST makes definitely more sense there instead of trying to apply it to EA where messages are first class citizens.