Hello, this is Jan Lehnardt and you're visiting my blog. Thanks for stopping by.
plok — It reads like a blog, but it sounds harder!
↑ Archives
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:
XML, SOAP, WSDL, UDDI, WS-Policy, WS-Security, WS-Eventing, WS-Reliability, WS-Coordination, WS-Transaction, WS-Notification, WS-BaseNotification, WS-Topics, WS-Transfer
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.
Of course, this excludes actual data retrieval from resources (using GET). There the response body is where the meat is. The data can be formatted and encoded just the way the client needs it and NOT specifically wrapped in XML1. So if the client is a JavaScript, the data can be in JSON. If the client is a web page, the data can be HTML and if the client is a PHP script, the data can be PHP.
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:
[1] Nothing, really, nothing against XML. It sometimes is just not the right tool for the job.↑