Some might prematurely conclude that REST has won based on Programmable Web data: 73% of the APIs are RESTful. But Steve Jones, a SOA practitioner, draws attention that those APIs are used by front-end systems doing data aggregation and not by the majority of enterprise systems, and REST is not yet ready for the enterprise.
Clay Loveless, former CTO of Mashery, held the presentation “Lessons from the Failure of SOAP” at Glue Con 2011, sharing some statistics from Programmable Web, an API resource indexer, showing that SOAP has grown over the years, but it has a smaller share than REST, which has had consistent growth:
In a response to these numbers, Steve Jones, Global Head of Master Data Management at Capgemini and a SOA practitioner, said that they do not accurately represent how REST/SOAP are used today because Programmable Web does not collect enterprise data:
So what would doing the same query on the likes of Oracle, SAP, IBM or Microsoft's enterprise technology stacks deliver? I assumed the number to beat would be huge and got ready for some serious searching.... but the number to beat is 2368... errr seriously? I've worked in single enterprises where they had more SOAP endpoints than that. When you include the libraries of WSDLs from SAP and Oracle and the Behemoth that is Oracle AIA has so many that Oracle don't boast about it as it might make it look complicated. Back in 2005 folks at Oracle boasted about over 3000 web services across their applications.
Touching on the REST vs. SOAP controversy, Alex Williams, an Editor for ReadWriteWeb, reported from Glue Con that SOAP is not dead but it is “undead and will remain that way for some time to come”, because SOAP is entrenched in the enterprise and it is hard to get rid of it.
Jones commented on Williams post, saying that SOAP is very much alive in the enterprise and REST is being still born:
SOAP isn't undead, its very much living in the enterprise and indeed being the only real viable approach when integrating package solutions from a number of vendors (a massive piece of enterprise IT). REST however barely registers, less than 2500 APIs after all these years of development? Pathetic.
REST for the enterprise isn't undead... it’s been still-born for over five years.
Jones also remarked in another post that REST has not progressed in the enterprise integration and governance for the last year due to problems related to publication, versioning and testing:
Let’s be clear, I'm talking here about REST as an enterprise integration approach, not as a way of exposing a Web API for content aggregation but as a functional integration approach for enterprises. Something to replace the "fundamentally flawed" WS-* that REST is so much better than. So what is the progress this year? Zip, zero, nada. Yup a few minor tweaks into enterprise stacks that say they can produce REST interfaces, but in reality most of them can't and the key problems of interface publication, versioning and testing remain unsolved.
InfoQ has contacted Clay Loveless and John Musser, founder of Programmable Web, in an attempt to get their reaction to Jones posts on enterprise and REST.
Loveless agreed with Jones that SOAP will stay alive in the enterprise for a while, but REST will prevail in the end:
I think Steve Jones illustrates a good point, which I mentioned in my talk: SOAP will live on for a long time, especially in the enterprise.
The enterprise is slow to adopt to change, and is heavily driven by the vendor-customer relationship. If a middle-manager in the enterprise can't spend some money on a support contract somewhere, they feel like they're not doing their jobs right.
The enterprise has always, and will always, lag behind the commercial space. In the commercial, B2C world, REST has won, and John's [Musser] numbers prove it. When companies begin realizing that they can't hire effectively for SOA positions, and that they can build faster and cheaper with REST, they'll start shifting. This won't happen for awhile, but it'll happen. Also, the printing press is dying, as is Blackberry, though plenty in both of those camps are busy denying that as well.
Musser, who held a keynote at Glue Con 2011 on the State of the API and showing the same data contained in the charts above, believes that a trend has been set and REST will eventually conquer the enterprise:
I agree with both Steve and Clay that SOAP APIs will have a long future within the enterprise. The primary driver may or may not be a technical REST-vs-SOAP decision, be it on technical merits or something from the CIO's office, but instead driven more by incumbency. As Steve notes there are thousands of applications and many enterprise tools that are rely on SOAP and WS-*technologies.
What I was referencing in my talk last week was that if you look back at 2005 there was indeed a strong SOAP presence in web-based APIs but if you look at what's happened over the intervening 6 years, it's clear that REST is taking a larger and larger share of the market. It's not so much about total number of implementations or endpoints to date, it's about where the trend is heading. And if you look at what enterprise-focused vendors are aiming towards, it's REST. They're of course not abandoning SOAP, but take a look at what Salesforce.com is doing (they've been SOAP only for nearly a decade and now are adopting REST, or a Microsoft's Azure platform).
We also contacted Steve Jones to get more details on why he thinks REST is not yet fit for the enterprise.
InfoQ: You said that REST has had zero progress in EA integration over the last year. What do you base your remarks upon? Do you have any numbers? Is it based on your experience inside the enterprise you work for?
SJ: I've seen some REST work done in enterprises but always at the Web end of the equation and never on the internal integration between enterprise systems. I also base it upon exactly those stats from the Programmable Web, an example is their one SAP link (https://streamwork.com/developers) which is indeed a REST API and working in the area where REST works... front end integration and aggregation.
The programmable Web lists less than 2500 APIs and only one from SAP and none from Oracle. This indicates just how little awareness the REST community has of the reality of enterprise integration and its challenges.
InfoQ: You noticed REST's progress for content aggregation, but you said REST did not make much progress for EA integration. Would you mind making the difference between the two domains? What does it take to make it useful for EA? Interface publishing and versioning?
SJ: Data vs. function. When I want to see all of the accounts from 5 different systems displayed on one page then a REST approach is great (as long as it’s backed by an MDM solution to enable the customer keys to be identified in each system). If however I want to create something that opens five accounts, communicates that to the billing system and does so in a way (and this is the critical bit) that the teams can work independently then REST breaks down.
Enterprise Integration is about separation of domains to enable them to work independently with well defined boundaries. These boundaries are often contractually enforced via outsourcing deals or technically enforced by package vendors. RESTs mentality is that these boundaries are fluid and that making them rigid is a problem, the reality is that having ridged boundaries is actually a good thing as it enables teams to work independently. Thus the ability to publish a functional contract (the WSDL) which can be consumed in multiple technology stacks is a key benefit of SOAP/WS-*.
To the point about REST and MDM, this is a good example of the boundary. REST needs to be able to aggregate information from multiple systems about the same customer. A "true" REST approach would have a central customer system that all people reference via a URI and thus this would be the unique ID. The reality is that systems like SAP and Oracle will always retain local copies of customer information so some form of functional integration is required and information synchronization. This is where WS-* comes in as it provides a way of publishing both the "create customer" functionality and the "sync customer" return.
The difference between SOAP and REST from a purely technical perspective is a pointless discussion (http://service-architecture.blogspot.com/2006/05/soap-v-rest-more-pointless-than-vi-v.html, http://service-architecture.blogspot.com/2006/09/why-rest-v-ws-is-irrelevant-in-two.html) the reality is that what enterprises need to integrate is the ability to publish contracts that can be consumed not simply in a technical sense but in a real human sense of understand how to invoke a capability. WSDL for all its faults makes this easier than REST.
The reality of enterprise integration is that taking an approach such as MDM has a bigger impact on the complexity and flexibility of integration than the specific technology used for the plumbing.
InfoQ: How do you see the future of REST?
SJ: Lots of hype and people complaining that others don't "get it" while ignoring the actual flaws would sum up its past to date. What I hope is that the REST crowd will wake up and start agreeing on a set of standard ways to describe the FUNCTIONAL interface for REST (http://service-architecture.blogspot.com/2010/01/define-standards-first.html) this really is the very basic stuff but many folks argue that this goes against RESTs principles. Maybe the problem is that REST is fundamentally about data traversal and aggregation and it’s not suited to more functionally oriented approaches.
InfoQ: How do you see the future of EA integration if REST is not the solution and SOAP is blamed for its complexity?
SJ: Enterprise Integration IS complex, it’s more complex than most Web Integrations that people think are complex just because they are high performance. Speed != complexity. There is complexity in enterprise integration but it has little to do with the technology difference between REST and SOAP, REST is significantly MORE complex today for enterprise programmes because of its inability to agree a standard way to define a functional interface.
Approaches that would improve enterprise and B2B integration would be the ability to add MORE formalism to these interfaces so there is less arbitrary documentation, as an example the ability to specify that a date of birth must be in the future or that a credit check has to be performed BEFORE opening an account would help significantly.
Blaming SOAP for the complexity of B2B and Enterprise Integration misses the point of where the complexity comes from. The complexity comes from the need to integrate multiple different business domains and a standard lack of core business and technology approaches (such as MDM) which would make this easier. The technical plumbing approach is just the bit that shifts XML across the wire, SOAP makes this EASIER than older approaches and so its reduced complexity. REST hasn't made it easier so it’s not being used.
Jones added on Twitter: “mosesjones: I might be wrong and REST will win in the enterprise but the REST crowd has to start being practical rather than technical.”
What is your experience? Is REST fitted for your enterprise? Have you solved the problems mentioned by Jones? Do you see REST taking SOAP’s place in the enterprise in the future?