Comments on: Post in REST: create, update, or action?

By: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems — Tue, 05 Apr 2005 23:41:39 +0000

Can REST be considered a web service?

By: Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems — Tue, 05 Apr 2005 23:40:33 +0000

Can REST be considered a web service?

By: Robert Sayre

Robert Sayre — Tue, 05 Apr 2005 00:22:56 +0000

“should I summarize it in a new post?”

Has it influenced your thinking? If so, yes.

By: Mark Baker

Mark Baker — Mon, 04 Apr 2005 15:56:16 +0000

FWIW, both POST and PUT can do creation; PUT for when the client knows the URI of the thing it’s trying to create, and POST for when it doesn’t.

By: Leigh Dodds

Leigh Dodds — Mon, 04 Apr 2005 13:28:04 +0000

For the APIs I’ve designed so far I’ve end up with POST doing the work of both create and update.

E.g. POST to /pets to create a new pet. The POST containing the required metadata, the server responds with a 302 with the URL of the newly created pet resource. This allows the server to keep control over the ids. I’ve justified this as considering “/pets” as a resource that I’m modifying.

Updates for an individual pet would be POSTed to e.g. /pets/lassie. The POST contains an XML document which can be the entire, updated pet description or just the revised elements. This is trivial when your API is mapping back to a relational system and you end up just updating individual columns; updates to document oriented XML might be a bit trickier.

I don’t understand your “/pets/actions/buy” example. Here I’m creating another resource on the server: a transaction, or wishlist, or adding to a cart.

By: David Megginson

David Megginson — Mon, 04 Apr 2005 13:24:59 +0000

I think the discussion here is more valuable than my original post. Will it show up in the weblog search engines, or should I summarize it in a new post?

Thanks, everyone.

By: Mike Champion

Mike Champion — Mon, 04 Apr 2005 13:17:36 +0000

Robert: That’s a good point. I’m happy agreeing that sites should conform to HTTP. I guess I think of POST in *practice* as a sortof generic doStuff() operation, but I wouldn’t want to press that point. My main skepticism is about the REST as a theory for how to build more complex systems on top of HTTP.

By: Robert Sayre

Robert Sayre — Mon, 04 Apr 2005 04:02:13 +0000

HTTP 0.9 includes the same definition of POST that Joe used (post a message to usenet or create a something somewhere). PUT and DELETE are namespace operations. PUT to create requires client control over the server’s namespace.

By: Ryan Tomayko

Ryan Tomayko — Mon, 04 Apr 2005 00:28:16 +0000

I’ve always thought POST made perfect sense for CREATE. “Post” as in “Post a new item”.

Take, for example, a RESTful interface to message board / forum software. URI space like the following makes sense to me:

GET / – Get links to the list of messages in the forum.

GET /id – View message “id”

POST / – Create a new message on the forum (response: 303 with URI to new resource)

PUT /id – Create a new message using the specified ID.

I think it comes down to whether the client understands how to create new pieces of URI space or whether the server needs to. If the server understands the URI space then POST makes sense, if the client understands the URI space then PUT makes sense.

There was some really excellent discussion on PUT vs. POST for new resource creation on the ATOM mailing list and Wiki back around November.

By: Mike Champion

Mike Champion — Mon, 04 Apr 2005 00:14:35 +0000

I agree about the “write code, not blogs” comment and really should just shut up about this, but am drawn to it like a moth to a flame, with similar results, at least on my productivity. Here’s what I would hope is my last word on the subject for awhile: Find the principles of Web development by induction from the most technically successful sites, not by deduction from Fielding’s or anyone else’s axioms. That is, identify those web applications (human-only or automated services) that are secure, reliable, scalable, capable of handling all sorts redundant or aborted operations without doing anything unpleasant, etc. … then identify what the common factors are. If they do turn out to be something like: (borrowing heavily from the Wikipedia article on REST)
* Entities conceptualized as abstract resources about which applications transfer representations.
* A fundamentally stateless client/server interaction where participants are not required to take additional steps to track states

* A limited number of well-defined protocol operations that correspond fairly closely with the basic CRUD functions required for data persistence.

* A universal means of resource-identification and -resolution: in a RESTful system, every piece of information is uniquely addressable in a single namespace through the use of a URI .

* The use of hypermedia both for application information and application state-transitions.

THEN, let’s all treat these (or Fielding’s original wording) as axiomatic and figure out how to write better apps by being RESTful. If some of these aren’t found too often in the wild, then let’s not waste energy arguing about how to implement them.

This has practical implications for what David’s post analyzes: Why not just use POST as a pragmatic way of sending entire XML files to a server? Why “fix” servers by opening PUT, in the world we live in where all sorts of slimeballs are trying to sabotage websites just for kicks? If it turns out that there is solid empirical evidence that the REST prescirption about operations should be taken as axiomatic, then sure, fix the servers in the way the theory prescribes. But if the REST principles just happen to partially intersect actual best practice, it’s not clear to me why practice should change to accomodate the theory.