As far as debates go, the API (Application Programming Interface) vs SOA (Service Oriented Architecture) dispute has been pretty high on list. Here you have API purists who push that APIs are the way to go while SOA proponents have called API an extension of SOA. But are API and SOA really that different? Or are they more similar than some would like to admit? Let’s look at things from an Enterprise IT approach.
When it comes to Enterprise IT, the main goal has always been to meet business needs. Understandably this involves things like availability, scalability, performance, security and so on. In other words, you have hardware, infrastructure and applications that aid in meeting business needs by aligning company strategy with deliverables. This is where API and SOA come in. With them, Enterprise IT can be offered as a kind of service as a result of both API and SOA making use of combined services to meet constantly changing business needs.
With SOA, business needs are placed at the forefront. Using SOA means you are using design principles which divide tasks and responsibilities into services which can work in conjunction to meet a need/objective. As such, you can identify the services you need to meet the business need and can thus create tools and resources.
As for APIs, they serve as a form of communication between software components. In other words, it's the actual implementation of the software design via routines, protocols and tools. More specifically, emphasis is placed on broadly deployed APIs and Open APIs (also known as Public API). What's the appeal here? With Open APIs, application programs and even websites can interact with each other and share data via REST, SOAP, and other web technologies.
If you take a look the differences between API and SOA in terms of Enterprise IT, there really aren’t that many.
Probably the biggest difference between API and SOA is the fact that APIs are more open for creativity meaning that there isn't just one way to use them. Moreover, they also support JSON formatting and are easier to work with on an external level. Additionally, whereas APIs can be used for both internal and external use-cases, SOA is predominantly used for internal use-cases.
But in the long run, such differences are fairly trivial.
Think about it. API and SOA share:
Architectural principles, especially in terms of infrastructure, manageability and governance.
The need to be secured, monitored, orchestrated, mediated and audited.
Both are services. Both rely on other applications and services which are often managed by other developers, organizations or different providers, though API do so in a more open fashion.
And really, SOA even makes use of APis in order to function properly.
All too often it seems like purists will get caught up in the battle rather than realize the similarities. API purists have even gone as far as to call SOA dead, but really with many SOA principles ingrained in API, that's hardly fair. Sure, API have unique attributes, but the bottom line is that both API and SOA have the same goals in mind and ultimately lend themselves to fulfilling an objective be it business needs or otherwise.