One for reads, many for writes

So we have GET and POST. And we also have PUT, UPDATE and PATCH. Please note UPDATE is the verb introduced by Web3S, while PATCH is the verb likely to be used in AtomPub based applications.

POST, PUT, UPDATE and PATCH are all about writes. They have different semantics. But they're about writes. Actually, POST and PUT can both be used to create new resources, depending on who is in charge (thanks to the Book). Also, POST with a Multipart-Related content type seems similar to this possible application of PATCH.

PUT is considered idempotent. Unless it is used to create new resources. Well, it's still might stay idempotent in this case, unless no POST is allowed. Otherwise you create your new resource with PUT and in no time someone will start POSTing to it after discovering it through GET and then DELETing it.

The point of this post is not to try to claim all these write verbs are confusing. They're not confusing as long as you know what you're doing, when to use those verbs and have built your resource handlers properly, etc. They can help you to add more meaning to the updates.

Knowing when it's better to apply POST versus PUT for ex is a useful thing to know. It can help you build a purest RESTful application. Rather than have a bunch of overloaded execute methods, it's appealing to have verbs whose names suggest some semantics.

When I see some healthy discussions when what verb should be used, it reminds me of some healthy discussions I've seen about how to write a good Java application for example. It's about the skills, about knowing your tools.

There's only one thing I don't understand : what difference does it make for WEB ?

Not yet, but may be I'll see it in some time. The main question for me is not whether it's better to have create() and update() methods or just several overloaded execute methods. Rather, will it make any difference to the WEB at large that some applications are using GET and POST while other applications are using GET, POST and PUT ? So far, discussions about when to use POST vs PUT etc focus more on the technical purity rather than on the interoperability.

For example, all the HTML forms out there use POST even when deleting resources and it has not crippled the WEB, hasn't it ? Future forms will use PUT and DELETE but what difference will it make for the WEB ?

This interesting example demonstrates how PATCH can be used to do what GData does today with batch updates. Yes, it's interesting, I'm sure it will work, but what difference will it make for the WEB ? Doesn't it seem a bit too complicated just for the purpose of avoiding overloaded POSTs ?

SOAP-based services are blamed for the fact that a lot of custom verbs are pushed over POST. In many cases it's a fair point (actually, I'd like to muse about it later). Now, as far as the interoperability in a RESTful world is concerned, one needs to know the semantics of a given application in order to decide when POST vs PUT vs PATCH vs UPDATE should be used. It's unlikely a tool will be written soon which will understand itself when to use which verb when updating a given resource. If you're using an Atom powered client then may be a decision will be made by the tool. But while no doubt Atom adoption rate will increase, it's also of little doubt that other RESTful protocols, both generic and custom ones, will also progress.

The popular argument that a uniform interface lets one switch the communities easily won't work with a lot of write verbs being used out there. This argument in itself is not very practical anyway. Uniform interface does not tell you about the application or when to use which verb. HTTP OPTIONS is there but it may not always help. Say, in Amazon S3 PUT is used to create new resources while in AtomPub it's used to update the state of a given existing resource.

At least I can imagine how one can write a truly generic tool, possibly working in a semantic web world (I wish someone wrote a book like RESTful Web Services about it), if all the resources out there supported a single update method.

A single generic read method is good enough for all. Why is everyone so fixed on having many write verbs ?

Also, I'm wondering, does a true interoperability exist only in the world of fantasies ?