That is to say, REST does not equal CRUD, dammit!

Sadly, even I made the flawed analogy of Rest and CRUD. It is an excusable one, because it is so easy to map POST to create, and PUT to update, but this misses the deeper semantics of the HTTP verbs, a mistake that I corrected in a later entry. In short GET, PUT and DELETE refer to specific resources, and in the case of PUT, the resource does not have to exist for it to be acted upon.

But perhaps more importantly, by shedding the CRUD (Create, Retrieve, Update, Delete) mapping from GPPD (GET, POST, PUT, DELETE) you can use REST the way it was supposed to be used. There is nothing wrong with using a POST to delete, update or create resources, as long as you are POSTing to the proper resource. For instance, you might DELETE /table/employee/emp723, or you might POST an entity containing delete instructions for ids 23, 237 and 239 to /table/employee. A POST might not actually alter the data of a resource, but might initiate a different action entirely. A post could, for example, tell a server to update a series of feeds.

Making the REST = CRUD analogy is flawed, and isn't helping the understanding of REST, rather it is limiting it, and turning HTTP into an SQL subset.