REST Vs. SOAP, Round 2REST Vs. SOAP, Round 2

Damien Katz, who created the innovative document-oriented database CouchDB, recently stirred up a hornet's nest of controversy among RESTful software enthusiasts with his post entitled "REST, I just don't get it."Katz says, "Just because SOAP is a disaster, doesn't somehow make REST the answer. Simpler is better, and REST is generally simpler than SOAP. But there is nothing wrong with a plain old POST as an RPC call." (REST stands for representational state transfer and is a collection of network architecture principles which outline how resources are defined and addressed.)

"I know what is wrong with SOAP, and it has everything to do with unnecessary complexity and solving the same problems twice. But what is the big advantage of making all your calls into GET PUT and DELETE? If POST can handle everything you need, then what's the problem?"

This caught my eye, since I've recently written about both CouchDB and SOAP/REST architectures recently. A few weeks ago, I suggested that Twitter, the popular microblogging site whose servers have gone down repeatedly in the past six months, should consider a document-oriented database like CouchDB to overcome the performance bottleneck caused by Twitter's MySQL relational database. CouchDB has several attractive database features: it's designed for extreme scalability and is easily deployed to multicore or multiserver clusters -- not to mention the fact that it's fault-tolerant with support for incremental replication and bidirectional conflict detection and resolution. Instead of storing data in relational rows and columns, the database manages a collection of JSON (JavaScript Object Notation) documents. Not the least of CouchDB's attractions is that it's schema-free and provides a RESTful HTTP API for reading and updating (add, edit, delete) database documents. Says Katz: "For CouchDB, REST makes absolutely insanely perfect sense. Read a document, edit, put the document back. Beautiful. But for most applications, enterprise or not, I don't see what the big win is."

Katz's post prompted a wide swing of responses that ranged from Dare Obasanjo's history of the SOAP vs. REST debate (highlighting the complexity of SOAP and the incompleteness of REST) to a few insightful comments from Dave Winer and Tim Bray about what RESTful Web services proponents can learn from remote procedure call (RPC) technologies like SOAP and XML-RPC. Joshua Haberman also agrees with Katz's opposition to one-size-fits-all RESTful solutions:

"The more a service looks like a filesystem, the more REST makes sense. The more any of its operations diverge from being dumb filesystem operations, the more REST breaks down, and the worse of a fit it is."

Obasanjo's followup post RESTful JSON: Bringing REST and RPC Closer Together offers some thought-provoking commentary that might help bridge the current gap in the SOAP vs. REST debate, including the following suggestion: "If you put together the notion of service documents with using JSON as the payload format for a service endpoint, you're close to getting the touted programmer friendliness of RPC technologies like XML-RPC & SOAP/WSDL while still building a RESTful service which works with the Web instead of against it."