

It is okay to use POST - dizz
http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
Roy Fielding on the usage of POST within REST, prompted by Tim Bray's recent article
======
thras
Use REST because it's a convention. As far as I can tell, there is no other
earthly reason to use it. It certainly doesn't simplify the coding of web
applications.

In fact, REST barely exists in the Django world. The problem that Rails solved
with CRUD, Django solved with the Admin interface.

~~~
ratsbane
REST simplifies web applications because it works with the behavior built into
the different levels of the web infrastructure. Browsers pop up a dialog box
if you try to go back to a page requested with a non-idempotent method
(anything but GET or HEAD). Caching servers treat non-idempotent requests
differently from idempotent requests, etc.

Understanding what REST actually means and whether something is RESTful isn't
always obvious. To me it means use the appropriate HTTP method as defined in
the RFCs; use the URL, including query string, as the sole resource
descriptor; use the request body only to contain new information. I get a bit
tripped up over what I understand to be Roy Fielding's objections to
maintaining state through cookies - I continue to do that, but with a vague
feeling of unease that I'm missing something.

~~~
thras
The problem is that REST only makes sense when your UI is all about data
entry. Sure, it's great there. You update things, you create things, you
delete things, you replace things. Wonderful stuff.

But as soon as your application steps beyond that, you're sunk. The user of a
web application only rarely interacts directly with resources. Individual
forms can be linked to multiple database objects or none.

What REST can't handle is any level abstraction between CRUD and UI.

~~~
ratsbane
REST doesn't tell you what to do with the information after it's created or
updated. Everything you might want to do through a web interface can pass to
the server through the narrow funnel of CRUD.

It might seem that an exception to that would be to initiate some action off
the server: send a fax, send some emails... but you can also look at these
instances as changing the state on the server such that such action is
requested. It's then up to another process on the server to respond to the
changes and update the state on the server to show the results of that action.

~~~
thras
Oh, I agree with the exception statement. That sort of shoe-horning is exactly
what goes on when you REST up a rich web-app. But how does it simplify
anything?

