This blog post is in response to the article SOA and RESTful interfaces: When, why they should be combined
posted by Tom Nolle, Contributor Published: May 6, 2013
Written by Vineet Joshi, Cloud Elements Co-Founder/CTO
In general terms, REST is a transport mechanism to expose a SOA service, so I think they’re very complementary in nature. The typical methods of exposing a SOA service are too heavyweight, and incompatibility has been introduced by implementations not following the specification closely for which I don’t blame the developer community, because reading the specification is worse than reading a DoD specification, let alone trying to understand the intent of the specification. For example, as long as one uses compatible versions of a client and service, let’s say 1.1, WSDL is supposed to be the mechanism to allow client and server to interact without ever having to know anything about each others platform, language or business logic. However, when the implementation does not follow the specification closely, there is no way client/server can work disparately, without a series of conference calls between client and server developer, to explain the implementation and hand-hold the client developer through the integration process. Remote Procedure Calls (RPC) had the same issues with the Interface Definition Language (IDL), leading to the Common Object Request Broker Architecture (CORBA), which failed. The Simple Object Access Protocol (SOAP) was Take 3 of the failed attempt to standardize developer usage of client/server interfaces, in some ways an attempt to normalize human beings.
The beauty of REST is in it’s flexibility, and in it’s lack of pretense to try and create a standardized transport that will never require client and server to know about each other. Although attempts have been made to standardize REST via REST Schema, etc., such specifications haven’t yet caught on universally. The simple, and likely the approach with the greatest chance of success, is to allow discovery of “flavors” of REST utilized via documentation, e.g., Swagger, IO Docs, etc. As these tools become more sophisticated, discovery and implementation of REST APIs will be the much wanted, and in some ways needed consequence.
In terms of security, the author of the posted article (referenced in the title line) talks about the developer having more control over the same with SOAP. In the purest sense, he’s right, but implementing a WS-I and the overload of WS-* specifications is not for the faint hearted. A friend of my colleague Atul Barve (Cloud Elements Co-Founder/VP of Product Development), back in the 1990s, used to say “Using the X Windows SDK was like making love through a barbed wire fence”. Well, WS-I is worse. Implementing security via REST is not necessarily a cakewalk, but a developer has choices upon which security specification to employ, rather than forcing a standardized specification that will never fit all sizes.
I do believe that SOA has a long life, in fact REST cannot really exist without a service-oriented architecture, but I think SOAP, and the WS-* standards are going down the path of RPC and CORBA. It is very difficult, if not impossible to standardize the input/outputs to a service. SOA gives architects the flexibility to expose business logic via a loosely coupled architecture, while REST gives developers the flexibility to use/view a service to fit the needs of the consuming application. With improved documentation and discovery of RESTful APIs, SOA and REST together, allow developers to have the best of both worlds.