From REST to SOAP

Do we really need yet another SOAP vs. REST discussion? I think so. I spoke with a relatively smallish web company, who we'll call OnTheFence that works in a business domain owned by Web giants. They are currently maintaining two similar distributed SOA APIs: one well used internal REST API and one experimental external client facing SOAP API. They took a survey of their competitors, which are major divisions of large companies, and found that they all use SOAP. Those major divisions strategically decided to use SOAP rather than REST.

That competitive analysis led OnTheFence to research the abandonment of their existing internal REST API in favor of a SOAP API to be used for internal application integration and external service exposure. They wanted my opinion on their architectural dilemma after they came to consolidation of their argument against REST:

1. Not a good architecture for service based APIs
2. Difficult to integrate with.
3. Not widely used for 3rd party exposures. If we expose to 2rd party we might need to implement SOAP anyways.

I posted this topic on twitter:

Next week, I'm going to talk to a web company that dropped REST in favor of SOAP. Looking forward to the discussion.

and I got some interesting responses:

chrislovecnm:

chrislovecnm: @sduskis I have had those discussions before to me wsdl == service, REST == crud. What is your opinion?
sduskis: @chrislovecnm The common idea that wsdl == service, REST == crud is exactly the issue in this case. IMHO, REST can do services.
chrislovecnm: @sduskis they can. But how do you do a contract w/o a wsdl? Just curious what you think
sduskis: @chrislovecnm What architectural benefits do you get by having a contract compared to a RESTful interaction? Tough question to answer
chrislovecnm: @sduskis Si. I only ask quality questions.
chrislovecnm: @sduskis IMHO REST gives you simpler access to data. WSDL gives you an interface. Interface is more complex while REST is more flexible.

I didn't respond to Chris yet. I simply don't have the easy answers to his questions, and I don't necessarily think that this particular company needs to be concerned with these specific issues.

Subbu Allamaraju (blog) said:

sallamar: @sduskis Wow - in 2009? They better have some good SOAPy story.
sduskis: @sallamar I expect this to be a great story. They're a solid Web 2.0 company, and still moving from REST to SOAP.

I met with OnTheFence a couple of days ago, and came away from this meeting with strategic and tactical perspectives on some issues of choosing an external service distribution strategy.

From a strategic perspective, I suggested that exposing their services through a RESTful framework would allow their clients to chose simpler integration with browser based applications. Giving their clients the choice of REST or SOAP gives OnTheFence an inherent competitive advantage over their large counterparts because of quicker integration and support for more media types. In other words, external distribution strategy requires anticipating your client's needs.

From a performance perspective, they were looking at some performance implications of REST APIs. The first was caching, which is built into HTTP which can be used by some REST frameworks. The second was the performance implications of content negotiation. A REST client can specify that it can understand a format that is inherently more efficient to marshal and unmarshal (such as protobuf or JSon+GZip).

From a tactical perspective, there are probably good ways to reduce the maintenance costs for exposing functionality through both SOAP and REST system. If they found the right development "best practices", they could perform a balancing act between the needs of a REST system and the needs of a SOAP system required to support the strategic objectives listed above. Now all I need to do is find those best practices that fit their chosen technology stack . They happen to really want to use Axis2, which does have a "REST" interface, although I'm not so sure that the Axis2 REST adapter would fit the proposed strategic objectives listed above (meaning it generates XML, and not JSon). In addition to the Axis2 solution, I'm going to explore a JAX-WS/JAX-RS integration. Either way, it seems like declarative programming paradigms are quite useful in SOAP/REST integration.

Back to the original ideas that OnTheFance had of REST, which we really didn't completely talk through during the meeting:

1. Not a good architecture for service based APIs - This is an interesting point. We as a community are coming to grips with the limitations of the REST is CRUD metaphor. That view was useful to get things rolling, but REST is more than CRUD, and we need good examples of how to do this. Jim Webber wrote How to GET a cup of coffee a while ago, and is working on extending that understanding. I know for a fact that REST services can be easy to write; IMHO, it's just a matter of disseminating that knowledge.

2. Difficult to integrate with - I humbly disagree here. "REST" is easy to integrate, as long as you have the right tools. As I said before, the browser has that right tools and can seamlessly integrate REST services into an application. The community is also constantly creating new tools to allow for even easier integration. OnTheFence could provide simple documentation along with .NET and Java wrappers that can make client REST integration a snap.

3. Not widely used for 3rd party exposures. If we expose to 2rd party we might need to implement SOAP anyways. - A bit of pllanning may give OnTheFence the ability to have both SOAP and REST interface with minimal maintenance costs. If the right approach was found, the consolidation and maintenance costs are likely to have significantly positive return on invenstment.

I'm pretty jazzed about this idea overall. Has anyone out there tried to do something like this? Do you have any feedback on my conclusions so far?

I'm Solomon Duskis, NYC consultant and a Java/J2EE guy. I work at Sungard Consulting Services in NYC. The postings on this site are my own and do not necessarily represent the positions, strategies or opinions of my employer. Solomon is a DZone MVB and is not an employee of DZone and has posted 11 posts at DZone.