Comments on: HTTP Status: 201 Created vs. 202 Accepted

By: Ben Ramsey

Ben Ramsey — Fri, 25 Apr 2008 19:43:34 +0000

Glen, I will eventually get around to talking specifically about the verbs themselves, but as a short answer, in the AtomPub service I’m building, we equate the verbs directly to CRUD, as the AtomPub spec recommends:

POST   --> Create
GET    --> Read
PUT    --> Update
DELETE --> Delete

However, I can see how you might PUT a new representation of a “collection” that the server would then interpret to add or remove new items to the collection, creating new resources, removing them, or doing both to different resources in the same action. Likewise, you could use POST directly on a resource to do a partial update, whereas a PUT essentially means “replace” and replaces the representation of a resource with a new one. I treat PUT loosely, though, because I don’t want people to be able to change certain values in the Atom Entry representation (i.e. atom:id, atom:published, etc.).

As you can probably tell, I have a lot to say about this, so I’ll make a full post on it sometime in the future.

By: Glen Gordon

Glen Gordon — Fri, 25 Apr 2008 19:21:37 +0000

Hi Ben, great couple of posts so far. I know you might get to the answer to this question eventually, but it bears asking now. You mention “using the 201 Created status code as a response to successful POST requests for creation of new content in the service” in here. What’s your perspective on the architecture of services when it comes to these verbs? Some folks say to map the HTTP verbs POST, GET, PUT and DELETE explicitly to each letter in CRUD. Others say to be more lenient and in a sense “overload” the POST verb, letting it sometimes be create, sometimes be update, based on the context of the URI. Plus, I know there are issues where some browsers don’t support all of those verbs, which would affect Ajax style apps trying to use XmlHttpRequest. So what say ye?

By: Dave Hauenstein

Dave Hauenstein — Fri, 25 Apr 2008 18:58:05 +0000

Great post. I just developed a ReSTful API for creating and viewing log buckets and log records. When a log record is posted to a particular bucket, it’s not yet written to the database. It’s first written to a que (which happens to be a text file) where a daemon will run and process each record. Since the log isn’t actually created at that moment, i return a 202 accepted. This implies exactly what you said above: it has not been created because there is some further processing to perform, but it was successfully received by the server.