Service Oriented Architecture (SOA) and Application Programming Interface (API) Management relate to each other in both complementary and contrasting ways. The fact that API is a much older term than SOA, but SOA came before API Management can make this relationship even more confusing, especially if focus is on the “API” part of API Management, when the “Management” part is what’s important. Let’s say that modern API management deals with SOA based APIs, but we still need the old-fashioned code library style APIs which run in the same process as the client code that uses them. SOA Governance is the part of SOA which has mostly evolved into API Management, but it’s important to remember that API Management cannot stand without the foundation of SOA.
SOA Governance has been about managing services within an enterprise, with an occasional exception of providing these services to business partners or consuming services provided by business partners. This includes service lifecycle management (designing, developing, testing, deploying, versioning and retiring), provisioning, security, mediation and other required aspects of governance.
API Management contains all the aspects of SOA Governance, but also adds things like Developer Portal and API Gateway. These are replacements/enhancements to traditional SOA Registry/Repository and ESB. They are motivated by exposing APIs to developers outside the enterprise and monetizing the APIs, but they are also beneficial within the enterprise. In fact, intra-enterprise use is the primary driver for adopting API Management today.
Some of the most important benefits of replacing traditional SOA Governance with the API Management approach do not come from any actual differences between the two, but from different architecture styles that are generally associated with each of these approaches.
Traditional SOA is generally associated with SOAP over HTTP or over JMS and XML payloads, while API Management is generally associated with REST over HTTP and JSON payloads. The interface of traditional SOA services was usually defined using WSDL, and while the latest version of WSDL can be used to define REST services, APIs are usually defined using WADL extended by particular API Management tools.
Architecture designs that are used with API Management usually also reject some old SOA concepts which experience has exposed as embellishments. These include things like service broker, UDDI, runtime binding of clients to service implementations, and ESBs that perform routing, choreography and transformation outside service implementations. The more modern architecture designs, usually associated with API Management, tend to use the “smart endpoints and dumb pipes” approach, where services are as decoupled and as cohesive as possible, and communicate over simple “dumb” mechanisms like HTTP and lightweight messaging. Message bus implementations are used for asynchronous message routing, and they are not ESBs that do all kinds of other “smart” things.
Interface design in SOA is usually based on a small set of known clients and their needs/requirements in order to implement some business process(es). With API management, interfaces are designed with specific clients and uses in mind, but also with an expectation that they may be accessed by other clients and used in ways that have not even been imagined yet. This leads to simpler and better service and interface design, and may be the most significant contribution of API Management to SOA.
