It’s true you can implement everything with GET and POST, but at some point there’s no need to do yet another Web stack. The more features that get adopted and technologies that support them, e.g. pub-sub, ajax, etc, the richer the overall experience.

I agree REST is a plumbing technology, so the only thing slowing the adoption of REST is the clear value to the end user, instead of the app developer. That sounds like a good blog post….

[1] http://web.archive.org/web/20001012075129/magi.endeavors.org/html/methodology.html

That’s a pretty good argument, but nothing about POST is self-explanatory, so unfortunately I think there is a minor flaw in the argument in that respect. As for the rest of your comment, PUT isn’t an update operation, PUT is more like CREATE… and so is POST. Comparisons to CRUD are commonplace but wrong. However, I do agree with your overall point that REST is more discoverable and self-describing, which isn’t surprising as that’s part of the stated goal.

I experimented with a REST setup that automatically mirrored XML data structures at deeper levels of the URI to match the PUT action’s defined behavior of writing an *entire* resource at a given URI. So if you wanted to change a customer’s address, but you didn’t want to re-write the entire customer record, you’d just PUT to this URI:

//site.com/customer/{customer_id}/address

There is no requirement that a resource be some unique atomic thing. A lot of developers seem to have a hard time with the idea that the URI doesn’t necessarily directly map to anything physical (like a URL does). Designing a RESTful architecture is almost like defining a language, compared to building a typical API. Kevin’s “gauntlet” challenge is a great example of how REST can quickly and easily expose a very natural-feeling solution to a problem:

//site.com/ticker/{client_id}/portfolio

There you go: a single URI that returns all fifty securities in the client’s portfolio. “One at a time” was never part of the REST concept. Better yet, if the client decides to watch a new security, you can just POST that new security back to the same URI.

Sadly, three years later the article is still relevant. The major browsers still don’t provide good support for PUT and DELETE, and even if they did, their support for security is so poor I’m not sure it would matter.

POST = CREATE
GET = READ
PUT = UPDATE
DELETE = DELETE

If you remove PUT and DELETE, how do I update and delete? I have to overload POST and then boom, you have to explain your API.
If a webapp is RESTful, you require no documentation to immediately start using it. You operate on the resources just like database tables.
Any database that supports SQL is useable by anyone who understands SQL. Same applies to REST.

There are many other benefits to being RESTful, these benefits are brought about by being to make assumptions about the state of a system, and how it behaves in certain situations, and what responses from that system means.

You can not acheive this with SOA because ever single serivice is different (so we needs WSDL’s etc etc). As more and more RESTful sites appear, we will see better and better interoperability between these sites, resulting in large gains in productivity and innovation as sites can “mash up” with one another.

the scenario you describe is trivially handleable by basic HTTP GET. I’m not sure why you think anything more is required. There’s more than on way to do it, so there are several implementation details that can be worked out in the HTTP GET, but why you think this is hard is beyond me. Do a simple GET to request the data from the server, get back an XML document, use the results to fill in the page. What’s hard about that?

REST is particularly attractive when compared with SOAP, XML-RPC, WSDL and cousins, which have complex protocols, require relatively heavyweight clients, and need a correspondingly greater quantity of developer time. In contrast, REST brings to mind command-line data retrieval: a method name (i.e. program pathname), optionally parameterized, returning data indicated by your parameters.

However: REST has become inextricably bound to the transport of choice, HTTP. The concept of REST, that by presenting a resource identifier to a service, you’ll receive the indicated resource in return, is simple and attractive. By weaving REST out of HTTP, however, REST inherits HTTP’s limitations, as you’ve amply pointed out, ERH. By definition, any request made RESTfully must be limited to your client and server’s available set of HTTP verbs. Working around that by creating additional verbs, you’re venturing into RPC territory, the REST camp’s declared natural enemy.

If you were to develop a traditional GUI application, with internal APIs to handle the front-end’s needs, would you think to limit your choice of methods to just get(), set(), drop(), those methods provided by a particular transport’s protocol? Might you also want redraw(), clear(), zoom(), whatever’s relevant to your app’s needs? I can’t imagine any developer worth their salt would consciously design-in such limitations.

REST has its place, particularly in exposing lightweight data services to the public, but don’t constrain yourselves unnecessarily. As browser-based applications increase in complexity, you may find yourself outgrowing the limits of REST.

Here’s a gauntlet thrown down to the REST camp: Consider an Ajax page presenting lots of information; say, a stock portfolio display of 50 tickers. When the underlying Javascript code makes requests to the server, how efficient will REST be?

Will the 50 requests be sent serially, or in parallel? If serial, your user waits while the requests pass through that one-at-a-time bottleneck. If parallel, the burden is now on the server, which is now multitasking among 50 simultaneous HTTP requests. Multiply that by simultaneous users – now you’ve entered a new problem space.

Contrast with request batching, wherein the 50 requests are rolled into a single HTTP request, sent to the server. Handling parallelism is now up to your data service implementation, and not constrained to the limits of the transport. RPC is batch-friendly: a batch request is just like any other request.

To the strict REST adherents, please detail a RESTful solution.

In reality, REST and RPC live and work side-by-side. While the REST camp struggles against RPC, the rest of us will apply either (or both) as the situation requires.

PUT and DELETE have the following use: to put files and delete files (resources, but really what other resources can be PUTed and DELETEted?)

So when you upload somethign to YouTube or Amazon, you aren’t stuck with that STUPID upload box. The best upload box I know of today uses mootools and Flash, and is at http://digitarald.de/playground/uplooad.html .

Now, with today’s server security, not everyone wants to be exposing their internal uri structure to customers. YouTube might not want you to say PUT myvideo at /users/greg/coolvideo.mpghaha. However, you can still upload files to a well defined “temporary” place and then put them where they need to go. And it can be done better than with multipart post data!

Greg

BTW, you write “POST is used for unsafe operations” whereas the examples after it are about (non)idempotency, not (un)safeness. Pushing a button twice is OK for unsafe actions as long as they are idempotent.