Monday, 16 September 2013

RESTful APIs are also SOA

I’ve been reading several papers, articles and technical documents lately on this subject. And I’ve become incredibly annoyed by several authors talking about “SOA Services” vs “RESTful APIs” as if they are completely different things and in occasions that compete.

The fact is that SOA is an architectural style, a paradigm, which promotes the use of software modules referred to as services that interact in order to deliver larger software solutions. That said RESTful APIs represent an important contribution to this style of architecture but conceptually speaking, solutions that implement REST APIs provide a service, they have service consumers, and the core principles on which  REST APIs services are built (i.e. statelessness, granularity, modularity, and others) and also the tools used seem pretty similar to what I would consider a SOA based solution.

Moreover using the term “SOA Services” to refer to XML/SOAP web services in my opinion is wrong. Although I admit that there is ambiguity when referring to web services that are defined using WSDLs, I don’t support this term. I rather use the term SOAP services. I’ve also heard the term “XML services” but who says that REST services can’t use XML (at least in the response)?
Service Oriented Architecture does not force the use of any particular technology; the complete opposite. As stated in the SOA Manifesto ( “SOA can be realized through a variety of technologies and standards”.

In fact, I see a lot of value in adopting WSDLs like document (like the evolving WADL) to define REST APIs and also use some of the WS-* standards to enhance RESTful services. A simple example is using WS-Security. This is a mature standard and instead of developers reinventing the wheel to address authentication and authorization concerns,  WS-Security could be used to secure REST services. I do however see a lot of value in implementing RESTful services in support of mobile apps demands.

In my view, there is no such thing as RESTful APIs vs SOA Services (or whatever some people call them). In my view, when talking about SOA, there are different types of services that can be created in support of different business problems. The business doesn’t care if you use SOAP or REST so long that the solution provided delivers the expected value to the business….don’t forget that.


  1. Totally agree with the post, to talk about SOA as such there is no difference in speaking both as the WebService REST APIs (SOAP), we should not regard them as completely different things (technologically speaking), and that if seeing it from the point SOA view, both are considered as services (REST and WS service) as 'Thomas Erl' mentions in his books. A service is a logic which has been applied to the paradigm of "Service Orientation" and during Phase Analysis are called 'Candidate Services' are considered 'Assets Company' (These services themselves may be of any technology included: REST and WS, that if defined standards).
    On the other hand, at the level of WS on the WSDL I agree very much as it provides a command-level interface for client / provider (Top-down), something that REST does not handle so far (WADL not formally standardized level of companies and vendors) and is liminado to define a good specification documentation.