The idea is to support both SOAP and REST in a single programming model and runtime. That is what the folks over at WSO2 are building in the shape of Tungsten.
Sanjiva spells it SOAPOX, but I spelled it out differently above to make the derivation clear: "Soap box" of course. Ironically most people on a soapbox are trying to argue for one style or the other, but SOAP-POX is about allowing for both. The term also works a joke – its a crate for packing SOAP, right?
Developers are going to need to support multiple API styles, as Sanjiva admits in yet another WS-* mea culpa. The tundra is definitely breaking up.
So, REST vs. WS-*? Nahh. That’s old .. now its SOAPOX .. REST *and* WS-* all in one. And its definitely better than Smallpox.
So why do we have all this debate? Its because WS-* implementors (including myself until we did WSO2 Tungsten and Apache Axis2), took the view that REST is not important and ignored it. Duh. We were wrong. Sorry. A thousand apologies. So now, we have a solution: both can be done using one middleware, one programming model and one set of tools.
Hear that? "Duh".
The synthesis is to use a kind of a SOAP POX "router" or SOAP-POX for short.
How does the Tungsten implemention work? If the application expects SOAP and the message is POX, the "router" creates a dummy SOAP Infoset to carry the message as a payload. If its not XML then it serialised through XML binary optimisation (XOP). If the the app just calls for a GET, then a dummy SOAP envelope is forwarded through the system to allow the URL to be dropped into the app as expected.
The Sri Lankan team at WS02 has also built a c version of Tungsten that can be embedded in Firefox. They are also looking at PHP bindings, and even an IE version.
Its pretty interesting work but then the proof will be in developer adoption. There is a new spirit of pragmatism at work in the industry and we’re going to see more mashups of API and development styles. This is just one example.
Neither WS-* nor REST are going away anytime soon: we’re just at the start of a SOAP-POX Derby.
.
Matt MacKenzie says:
April 1, 2006 at 5:33 pm
Interesting. I wasn’t aware that bridging the two models was that big of a deal.
On he other hand, I value REST for its simplicity and purity. I’m not sure that I would want to put a middleware layer between my code and the REST loveliness if I was a developer of an application that didn’t also need SOAP client support (e.g. A flickr application).
Flex does a great job of making REST and SOAP invocations simple, maybe a better approach is not middleware, but better client libraries.
james governor says:
April 5, 2006 at 10:42 am
no that absolutely right matt. you wouldnt want to introduce layers you didnt need. but if you were blending styles something like this seems to make a lot of sense. also look at eBay, say, which offers both styles of API.