Akana Platform Free Trial

Get Started Today »

Sachin Agarwal

There has been a lot of talk about APIs vs. SOA, and there is still a lot of confusion about whether APIs are different or similar to SOA. The needle keeps swinging from one side to another, with API purists trying to detach themselves completely from SOA and the SOA die-hards claiming that APIs are just an extension of SOA.

From the perspective of SOA Software, having served hundreds of Fortune 1000 customers that are either using our products for only SOA,  APIs and a growing number that are now using for both, the real answer is probably somewhere in the middle.  APIs share essentially all of the basic architectural principals as SOA. SOA stands for “Service Oriented Architecture” and it fosters business through linked services. APIs embrace essentially the same goals, but are more open, easily consumable and support human-readable formats (JSON). APIs are also relatively more amenable for external consumption and have strong business affinity in that they can be branded and marketed as products.

A few weeks back we were at the Gartner AADI Summit at Las Vegas. Some of the best minds in the industry gathered and the focus of the conference was the impact of “The Nexus of Forces” (aka SMACT – Social, Mobile, Analytics (Big Data), Cloud and the Internet of Things) on application development and integration. At the center of this discussion were APIs and SOA. The key take away – APIs have their merits from being more open, easily consumable, mobile friendly, being more business oriented, but from an infrastructure, manageability and governance perspective, APIs are more like SOA.

For API programs to be truly successful, they need to be planned and designed right, have the right level of operational and policy controls and should be effectively monitored, analyzed and governed. The last word (“governed”), often scares away developers, but it is essential that you build your services to meet your business requirements, ensure that these services meet the security and compliance standards set by your respective industry/company and that changes in your infrastructure do not break your APIs or the thousands or potentially millions (wow!) of apps that are using your APIs.

Here are 6 points to keep in minds when assessing the similarities or differences between APIs and SOA and choosing an API Management solution:

  1. While APIs are generally associated with REST/JSON and SOA is associated with XML and SOAP, SOA is more than just a protocol. SOA stands for “Service Oriented Architecture” and is an architectural best practice around building de-coupled applications and fosters service re-use. The API Economy is also all about creating services and making them available in an open fashion.
  2. APIs can be used for both external and internal use-cases. The key difference between APIs and SOA being that APIs are more open, well documented and can be often self-provisioned, with little or no guidance, making them better suited for mass developer/partner consumption. SOA or XML services are pre-dominantly used for internal use-cases, though they are prevalent in a number of external B2B scenarios.
  3. While APIs are currently associated with REST and JSON, there are other protocols like web-sockets, MQTT etc. that are gaining prominence for specific use-cases. Just as SOAP has it merits and limitations, REST will be replaced by something else. API providers should look at deploying API Management platforms that future proof (and past-proof with SOA support) their deployment with an unified infrastructure, rather than taking a tiered approach. You do not want to deploy another tiered infrastructure once another protocol surfaces
  4. Both APIs and SOA services have to be secured, monitored, orchestrated, mediated and audited. These operational aspects of APIs and Services are often not associated with the respective message protocols, but are characteristics of the specific business service or operation they represent. In the services parlance, the common terminology applied to these operations is Policies. You should look at deploying a unified policy management across all your services, irrespective of the protocol they are tied to, in this case whether they are APIs or SOA.
  5. API and SOA are both services. They depend on other application and services, which are often managed by other developers, organizations and even completely different providers. Changes to these dependent services need to be managed and governed, as they could impact your API for SOA services. The architectural principles around security, compliance, policy management, monitoring and analytics are same or similar.
  6. Both API and SOA services have a lifecycle, which spans beyond just versioning. You need to manage how they are planned, have tools that support the development cycle and integrated your SDLC tools, can be migrated with from different environments (ie from dev. to stage to production) and can be retired without adversely impacting your or your customers’ business.

So while APIs have their own unique characteristics, at the core they are not that different from SOA and enterprises should try to use a common infrastructure to manage and govern the commonalities between them, rather than deploying redundant or “tiered” infrastructure.

Share Button


  1. Thanks a whole lot for this clarification.

    What I gleaned, at their core, from an OOP Perspective, APIs can be considered children to SOA Services. And so they can override and extend the properties of SOA.

    For example, their message formats tend to be JSON, a human readable format as opposed to XML that SOA Services tend to use.

    So, if I ain’t mistaken, an API could be considered a SOA Service but a SOA Service isn’t an API.

    Thanks a whole lot again.

    I’m a fan of your organization and hope to some day work there.

    Hearty cheers.

  2. thanks. this is quite clear.

  3. A diferenca entre SOA e Web APIs e:
    Web APIs sao Fremwork; e a comunicacao entre um aparelho eletronico e um outro atraveis de www ou a internet

  4. Nice explanation.

    I have been people referring services from many names like SOI, SOA, IP and now APIs with more external access.

    While internal systems consume SOI services, APIs focus has bee providing access to partners, developers community to collaborate for open innovation using sandbox based access

  5. SOA is a traditional term whereas ROA is current.
    Both SOA and ROA are architectural patterns.
    SOA can be implemented using SOAP, Jini, CORBA and REST.
    Traditionally SOA has favoured mostly SOAP and XML though can be implemented with REST and JSON.
    Entire Industry moving from SOAP to REST has changed terms from Assets to Resources.
    To favour REST and JSON, SOA has been reinvented in to a new term called ROA. ROA implementations/end-points are called API.
    So API is essentially an ROA pattern implementation.
    It is more like you want to differentiate between SOA and ROA instead of SOA and API.

Add a comment