Axway's Tom Burnell
A famous mullet-wearer
SOAP and REST are not a case of either/or. Like the mullet, you can use SOAP and REST together. REST-in-the-front enables developers to find your services in an API Catalog, then quickly use them in their apps or site. SOAP-in-the-back connects to internal infrastructure (e.g. .NET infrastructure which still mostly uses SOAP) and allows you to take advantage of SOAP features like WS-Security.
This is what caught my eye in the excellent recent article "The Myth of the Private API" by George Reese at Dell:
The Dell MCM software acquired from the company I founded, Enstratius, has both a public RESTful API and several internal SOAP APIs. We neither publish nor talk much about the internal APIs. What’s important to note, however, is that a customer can do anything they need to do using the public REST API and we’ve also taken steps to make sure that customers can’t reverse engineer and leverage the internal APIs.
It's REST in the front, SOAP in the back :)
My colleague Tom Burnell is speaking on exactly this topic - "REST, SOAP, Hypermedia: When, Why & How to use what" at the Nordic APIs event in Stockholm next week. He'll be talking about an example where an Axway/Vordel customer (a large European energy provider) needed to decide on REST and SOAP for their APIs, in an environment that would include Internet-of-Things devices (Smart Meters) and also an enterprise back end. Using an API Gateway, they got the best of both worlds - REST and SOAP. [ And yes, the captions are reversed at the top of this article - Tom has a very sensible short-back-and sides - the mullet photo is Chris Waddle back in his mullet heyday ].
Randy Heffner from Forrester also recently published research on how organizations are designing APIs. He has some interesting statistics on REST and SOAP. He writes about how each can apply in different circumstances, based on interviews with architects at organizations that use APIs both internally and externally. I'm proud to have been one of the interviewees for this report, and I highly recommend getting a copy of it.
Converting REST to SOAP is, in fact, one of the top use cases for an API Gateway, for this very reason. Of course, the mechanics of converting REST to SOAP is just one part: You also will probably want to propagate client information (obtained via the API Key or from an OAuth JWT Token) back to the SOAP layer (e.g. converting it into a SAML Assertion with Attribute Statements). That is also what an API Gateway is used for.
In this way, you get the benefits of the API Mullet - "REST in the front, SOAP in the back". Just watch out for the haircut fashion police...