Leonard Richardson and Sam Ruby are writing a book about web services and REST. They see superficial bloat in the way web services are built today. In short, they say to build a web page, you only need to know HTTP and HTML but to build Web Service a huge load of technologies has to be integrated:
From a conceptual point of view, web pages appear to be the modest, hard-working older brother of the good-looking blabbermouth web services. How come?
REST defines web services with the tools of web pages—HTTP and URIs. Those who claim that this won’t scale the book simply asks why the web scales when it is based on the same tools?—Touché.
With REST every resource has it’s own URI, just like a web page is uniquely identifiable on the web. Changes to these resources are realized using the various HTTP methods. Where web pages mainly use GET and POST, REST leverages the entire fleet. For example: DELETE to delete a resource, PUT to create one and POST to send changes. All this instead of creating a document that conveys the same information in XML and sending it to a SOAP server.
And this is only the first part of the communication of a web client to its server. In the REST world most of the information that is sent back by the web services server (duh) is passed using standard HTTP response headers. 200—everything went smoothly. 404—sorry, wrong number. 503—We’re no 24/7. 301—recipient moved someplace else. Again, a standard HTTP header already holds nearly all information ever needed; and that with a few Bytes only.
The power of REST is that it all sounds so obvious that makes it wonder why there is SOAP at all. The components, for example HTTP implementations, are rock-solid in any language, they are super fast, nearly bug free and proven to scale in the real world. Reusing them results in less development costs, less maintenance costs, more resources left for other things. It is not wise to use them, it is stupidhardly justifiable to not use them.
For these obvious reasons, I guess, Damien chose a REST interface to CouchDb. CouchDb as a document database handles a lot of resources and they can all be manipulated with all the REST goodness above: Want to create a new database, just PUT it onto the server. Want to delete a document, just DELETE it (I feel I talk to someone from the last millennium, doesn’t this sound obvious?).
What CouchDb offers is the topic for another post. Here is a teaser:
Built-in super-efficient on- and offline replication with lossless conflict detection and resolution.
Fault tolerance at the CouchDb server design level. If a component crashes, it just gets restarted. Go Erlang!
Changing data only takes one seek().
 Nothing, really, nothing against XML. It sometimes is just not the right tool for the job.↑