RESTful POSTing

Thu, 21 Dec 2006 14:36 UTC

In my effort to clean my plate of blog topics, here’s yet another post for this week. I promise to keep this one much shorter . . .

When discussing RESTful Web Services, I’ve often been known to say that I find it difficult to envision how POST fits in with the REST model. This is because my thinking has been stuck in the past with the old way of doing things. For example, consider the following form that uses the POST method:

<form method="POST" action="create-customer.php">
Name:    <input type="text" name="name" /><br />
Address: <input type="text" name="address" /><br />
E-mail:  <input type="text" name="email" /><br />
         <input type="submit" />
</form>

This form is simple enough. When the user submits it, they send a POST request to create-customer.php to create a new customer in the system with the given name, address, and email values. The problem here is that create-customer.php does not follow the REST model. It does not uniquely identify a resource. Instead, it merely processes data. If I were to call it with a GET request, what would it return? Maybe nothing. This is the RESTless way of doing things.

The RESTful approach requires that all URIs uniquely address a particular resource. With this in mind, an attendee at a recent Atlanta PHP meeting pointed out that the creation of a new customer could be as simple as changing the POST action to /customer. Again, the light bulb in my brain still did not light up because I was thinking about the “old way.”

I suggested that /customer, while it accepts POST data, would still return perhaps the newly created ID of the customer after creation, and this does not represent a unique resource. He pointed out that, when POSTing, you don’t have to get back a unique resource, but if you were to GET it, you should. Thus, when you GET /customer, the response might include an XML document listing all the customers. However, POSTing to it, might create a new customer that gets “inserted” into that listing. Likewise, GETing /customer/1138 returns an XML document of customer data for the customer with ID 1138, but POSTing to it would update the data for that customer.

That’s when the light bulb clicked on, and I realized that it is, in fact, possible to design a RESTful application that makes use of GET, POST, PUT, and DELETE in a very RESTful way.