What is the difference between an API and SOA

Question

There are a lot of What is the difference between... questions out there but I couldn't find this one.

Wikipedia says this about an API

An application programming interface (API) is a source code-based specification intended to be used as an interface by software components to communicate with each other.

And this about SOA

SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services.

Aren't both technologies where you present services to other services?
Could someone expand on this?

Answer 1

Service Oriented Architecture is an architectural methodology. It is a way of specifying separation of responsibility from a business oriented point of view into independent services, which communicate by a common API (often but not necessarily by publishing events to a bus).

As an example, you could have one service responsible for capturing customer orders, which publishes an OrderCaptured event to the bus; and a separate service responsible for tracking when the customer is billed and how much is owed, which subscribes to the Bus and responds to the OrderCaptured event. The first service might not need to know anything about billing due to the separation of responsibility. And the two services don't need to know about each other either, only about the events going on around them.

An API is an interface that a component/service exposes so that other components can communicate with it. In the example above the Bus is providing a common API for a number of services to communicate.

In summary:

API = any way of communicating exposed by a software component.

SOA = a set of enterprise architectural design principles to solve scalability issues by splitting responsibility into services.

Answer 2

In other Words:

SOA is the Architecture pattern.

An API is one of the ways to enact or to enable the SOA pattern.

SOA is the "Planning" {Blue Print} design method.

API is the actual implementation of the design.

Answer 3

The Concise and Brief version:

API is a layer for providing data access, via http, web sockets, and more, and are more mobile friendly. These API's should be architected with SOA support in mind, and currently use modern technologies evolving around JSON and REST.

SOA is more A2A and B2B Business solutions layer where when business need to pass data back and forth between different types of medium, API's are built, and business rules are built around that. Technologies are normally XML, RPC, and SOAP.

Both use interchangeable technologies. Security can be addressed on both, SOA normally so, API's less so if its purpose is to serve open data.

Answer 4

Seems like there are a lot of opinions about this; it's an interesting read. Here is my take.

SOA: SOA is a services-centric architectural pattern for constructing and accessing suites of software components/services (as was noted in the answer above). SOA principles that form the SOA pattern can be found in many places, not all of which are consistent with each other, making SOA a somewhat nebulous term. A SOA service can be built with almost any modern software development technology set (see below).

API: Generally the term 'API' is used to mean the specification of how to programmatically utilize or interface with a software solution. It can refer to things such as the specifications a programming language and its components (Java APIs), the specification of how to access and/or extend a COTS solution, the specification of how to utilize a service or set of services (including the signature or data structure related to interfacing with a service), etc.

SOA and API: An API for a SOA service could include the conceptual, technology-agnostic specifications of the service (ex: one data element will be the last name of a customer), as well as the physical, technology-specific usage specifications for each physical instantiation of that SOA service (ex: two instantiations will be available, one using a JSON layout and the other an XML layout, each containing roughly equivalent physical specifications for the 'LAST NAME' data element).

Misconception: The term API should only be used to refer to RESTful or 'simple, lightweight' or JSON-based interfaces (side note: RESTful is not equivalent to 'simple' or 'lightweight'). Actually, an API can be structured following many patterns using many types of technologies, including WS* based services.

Misconception: SOA strictly follows WS* or other 'complex, heavyweight' interface approaches. Actually, SOA services can be constructed and consumed using almost any modern software development technology set, including RESTful approaches or JSON files.

More on SOA: SOA is an architecture pattern built upon the concept that capabilities should be instantiated as services that have a crisp usage specification, and so can be utilized by any software component 'client' that can follow that usage specification, irrespective of the technologies upon which the service was developed or upon which the 'calling client' was developed. Well written services should be highly cross-compatible.

Because many open source providers and vendors have built SOA oriented frameworks that are based upon XML based approaches, notably the WS* set of standards, SOA has sometimes been mistakenly restrictively associated with WS* and/or XML related approaches. But in reality, SOA, as a conceptual pattern, is agnostic of technology. One conceptual SOA service could be instantiated once or multiple times in many forms, each instantiation choosing from a variety of technologies (XML, JSON, WS*, a REST approach, Java, C++, LAMP, ...) as determined by the designers and developers of that instantiation.

An SOA solution or solution ecosystem is one architected upon SOA principles; it is composed of services that are built and utilized following SOA principles, again, using whatever technologies the developers choose.