The API Mullet - REST in the Front, SOAP in the Back

We all know the old joke about the mullet haircut - beloved by soccer players and 80's bands – "Business in the front, party in the back." But how about the API equivalent? The API Mullet is actually something of a reverse mullet. In the front, there is the party side: REST – suited to pizza-fueled hackathons, and quick application hookups. In the back, there is the business side – SOAP – more enterprise-focused, and the basis for B2B formats such as ebXML.

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. 

http://programming.oreilly.com/2013/09/the-myth-of-the-private-api.html

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...