Why hasn't REST succeeded in the enterprise? Not of course because it isn't actually any better than SOAP for enterprise scenarios and is indeed much, much worse in many. Nope.
But first there is the reason why REST is successful
His presentation showed that 73% of the APis on Programmable Web use REST. SOAP is far behind but is still represented in 17% of the APIs.This is like going to France, doing a language survey and declaring that French is the most popular language in the US. 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. Now before people bleat about this being proof of SOAP complexity... that just makes you a hypocrite if you on one hand use the ProgrammableWeb stats as "proof" of RESTs success but then try and use the massive volume of WSDLs out there as proof of SOAP's "complexity.
I'm also here not even into the global standards that use SOAP every day for B2B, people like SWIFT, Open Airlines... shall I go on and on? 2400 APIs is a success? SOAP isn't anywhere near that? Like I say its like going to France and claiming French is the most spoken language on the planet.
All this just proves what I've said for a long time. REST works for information traversal, but its not set up for the enterprise. So what is the issue with REST not displacing SOAP in the enterprise?
"All the tools, hires, licenses & codebase has been built around SOAP for a decade," Loveless wrote on Twitter. "Hard to turn on a dime."
Wow, the bare facedness of this statement is hard to beat. REST has been kicking on this door for over half of that time and some folks argue that in fact it predates SOAP. So it really is bullshit to claim that its all the fault of tools & codebase. SOAP replaced old EAI approaches in a couple of years in new enterprise projects. We went from a situation with everyone in about 1998 doing proprietary EAI integration, with occasional CORBA for RPC, to everyone by 2002 doing Web Services with some JMS. People in 2005 were telling me that REST was the future and REST would win, and now SIX YEARS LATER people are bleating about 10 years of SOAP adoption...
If an approach is better for integration in the enterprise it will be adopted. REST isn't better, yet, for enterprise integration because it fundamentally remains a developer approach not a professional enterprise approach. SOAP isn't complex, technically it might suck (hell my father said "great we've now got enough processing cycles to burn that ASCII-RPC has finally made it") but conceptually its simple, and when managing complex estates with lots of different people that conceptual simplicity on the head.
Michael Cote of Redmonk hits the nail partially on the head when he says
"As enterprise development teams start including cloud technologies in their applications, incompatible cloud platforms and APIs will be a huge road block," said Michael Cote, analyst at RedMonk. "We're already seeing a clamoring for tools and services that integrate this spaghetti bowl of end-points, and they're only going to become more important to realizing the benefits of cloud development."In other words the lack of a formal contract and standard interface mechanism remains the real reason why REST isn't being adopted in the enterprise.
What SOAP did was solve a problem that the enterprise had. How do I describe integration interfaces so my systems on different technology stacks can communicate and do so in a way that enables my teams to work independently of each other. REST does not solve this problem in an effective way and bleating about "dynamic interfaces" being "better" misses the whole point of what has made B2B and Machine 2 Machine integration successful down the years, namely a focus on people-centric approaches rather than technical centric ones.
Unfortunately with REST there appears to be an active movement to stop this professionalism creeping into it and defining new standards that will actually make REST better for the enterprise.
REST needs a standard way to publish its API and for a way to notify changes in that API. This is a "solved" problem in IT but for some reason the REST community appears to prefer blaming others for the lack of enterprise success of their technology rather than facing up to the simple reality:
SOAP got some things right and the biggest thing it got right was a shareable and toolable contract (WSDL) which enabled interfaces to be published in a standard way which included by functional and data standards.
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... its been still-born for over five years.
Technorati Tags: SOA, Service Architecture
8 comments:
REST APIs? Wow, and here I thought it was about resources and well defined verbs.
I'd thought that as well... but apparently not according to these experts.
> REST needs a standard way to
> publish its API and for a way to
> notify changes in that API.
In fact, REST does have a standard and very rigid "API" (although I agree that's not really the right term) at least in its common instantiation in the Web through HTTP, HTML, etc.
Just trying missing out the blank line between the headers and body of a HTTP request and you'll see how inflexible that API really is!
But the essence of REST is that the functionality available through the API is defined by the media type, in this case HTML. Notwithstanding the reality of "tag soup", this is also defined quite precisely, but because so many different pages/applications can be defined by HTML it is also very flexible.
The API defined by the Web therefore is all of the possible pages/applications that can be defined by the Web's media types, including HTML.
This is all very nice and you can achieve similar things with SOAP/XML by using features such as xsd:any and by inspecting what you receive.
The problem is that it also doesn't narrow down the specifics of what may happen in any particular interaction. If you just want to exchange an invoice or purchase order, you really only want to agree on exactly how you will represent and deal with those items. The (purist) REST approach says that you need to code your application considering that *any* possible results may happen.
In REST, there is really just a single client application - the browser - that can implement any application in the API space defined by HTTP, HTML and so on.
The fallacy here is that the browser is really just an *intermediary*, not an application endpoint making intelligent decisions about what it wants to achieve. This leaves rather too much to be defined and agreed "out of band" between the human participants in the interaction, which as you say doesn't work particularly well when you're trying to coordinate system-to-system integration activity amongst many development teams and organisations under different commercial contracts.
Steve, thanks for the call out.
I have nothing to gain or lose from the transition of attention from SOAP to REST. As an author of a book on Enterprise SOA, I would argue that your opinion is a little biased on the SOAP side.
Steve, the world always marches on toward simplicity. Look at CORBA, as you mentioned in your post. Those who stand to lose from that forward progression often argue against it the loudest.
Mike, REST doesn't have a standard business/people API it has a low level technical API that is essentially worthless when it comes to teams collaborating on large scale enterprise developments.
Clayo, if you'd read my book on SOA you'd notice it doesn't talk about technologies once and I've regularly argued that SOA isn't about technologies at all and that you can do SOA and implement in REST, SOAP, legacy or flying monkeys.
REST isn't winning in the enterprise because it ISN'T simpler. If it was it would be adopted. REST solves a question that the enterprise doesn't ask... "How to do dynamically changing interfaces"
It seems like sort of a straw man argument. There are a lot of really, really bad SOAP interfaces out there. There are a lot o really bad REST based interfaces out there. Bottom-line, there are a lot of really bad interfaces out there. If you want to see a REST based interface done right, go look at Google Data Protocol. It does a good job of defining a REST-based interface with Atom and AtomPub.
My personal gripe against SOAP and WSDL is that people are taking a decent technology and making it overly complex. Also, they don't have good support outside the normal Java an .NET crowd. For example, I cannot find a WS-* messaging solution that supports JavaScript, Python or Ruby. But I can use AMQP with any of those technologies.
If you use the word "bleating" too much, it sounds like *you're* bleating ;-).
It's been another three years. Would be fun to see your take on an update on the maturity of Rest Web service practices since this post?
Post a Comment