SOAP vs. POX vs. REST

, Nov 6, 2006

So, we’ve got another of those REST-vs.-SOAP debates again … or, to be more exact, a SOAP-vs.-POX debate that has somehow turned into REST-vs.-SOAP. Whatever.

Sam Ruby started the discussion by referencing a piece from Leonard Richardson. WSO2’s Sanjiva Weerawarana chimes in:

So if you want security, reliability etc., you need SOAP (or you have to invent your own version of it and convince others to use it too .. good luck). Obviously not every scenario needs all that muscle: that’s why the approach taken by Apache Axis2 is the right way to deal with this: give a common programming model for both clients and services and let us middleware weenies worry about whether to SOAPify the requests and responses or not depending on your business policies.

As verified in a private email exchange, Sanjiva is very much aware that Axis2’s REST support is, in fact, only supporting POX. Mark seems to view this as another REST-vs.-SOAP debate; I don’t think it is.

So what’s the difference between POX/HTTP, SOAP, and REST?

  • REST is an architectural style that is independent, but compatible, with XML. It’s about identifiable resources, resource representations, a fixed (uniform) interface, and linking. HTTP is REST’s most popular instantiation.

  • POX/HTTP means exchanging plain old XML documents over HTTP. RESTful POX, i.e. using XML in a RESTful manner, would mean POX is a subset of REST. Many, if not most POX applications don’t care about REST very much, though — they’d thus be part of a distinct set of applications.

  • SOAP is a standard document format for building high-level protocols. Anything that uses SOAP is (by definition) not just using plain old XML, and thus not POX; it may be RESTful, unless it violates REST principles.

So there can be RESTful SOAP applications, and RESTful POX applications, and non-RESTful SOAP applications, and non-RESTful POX applications, but no POX/SOAP combination.

Although I usually agree with Mark, I’ more with Sanjiva here: if you want to put message metadata into your XML, SOAP offers a standardized (and very simple) way to do so. No XML-based format one could invent would be any better, and even from a REST standpoint, using standard formats instead of proprietary alternatives is preferred.

As I’ve mentioned before, I don’t think the original debate started out as a REST-vs.-SOAP, but as a POX-vs.-SOAP discussion. Nevertheless, Steve Loughran has a great list of things you lose and gain by not using or using SOAP.

In my opinion, REST + standard XML formats, wrapped in SOAP where you need it, makes the most sense.