SOA has been main stream for about a decade, modern style APIs are a more recent industry topic. Both have proponents, and both address business and IT concerns alike. So what is the real difference between these two approaches to integration and do you actually need to choose between them?

The core concept in SOA is the notion of a Service. The Open Group defines a service as “a logical representation of a repeatable activity that has a specified outcome”. Other definitions of the service concept are very similar. Services are self-contained, are a “black box” to their consumers and have a well-defined interaction contract. From a technical perspective these are characteristics holding true for any well designed API, in other words technically an API is also a service. In that case are APIs just another name for Services? There are many similarities but one very important difference – the objective intended to be achieved with their design.

APIs and Services - no text

My earlier blog “What is an API and why do I care?” describes the product nature of APIs, the fact that they are inevitably aimed at the needs of a particular group of consumers. To a consumer, using an API is about speed, expediency and less to learn. Those design criteria are the fundamental difference between APIs and the classical notion of a service, at least as seen from the perspective of the service provider:

– To a service provider, reuse is about effort to deliver. To an API consumer, reuse if about speed to deliver, no matter the cost to the provider.

– To a service provider, sharing is about effectiveness. To an API consumer, sharing is about expediency, if it isn’t expedient the API will not be used.

– To a service provider, encapsulation is about less to change. To an API consumer, encapsulation is about less to learn, if the interface is complex the API will not be used.

How often have we not seen an SOA initiative slowed down by conflicts between service providers and service consumers on what constitutes a good service interface? On the one side a mobile developer just wants it to be simple for their particular app, on the other side the backend team wants everyone to use the same standardized service and data model. Instead of forcing a resolution of this conflict, is there a way to meet both needs without incurring prohibitive cost?

There is a historical analogy in the evolution of databases. The first generations of databases were focused exclusively on the internals, the tables, schemas and data procedures. Quickly though, it became obvious that there was a need to expose controlled subsets of data in a particular form, fitted to a particular group of data consumers – and the notion of a data view emerged as a core capability in most modern databases, a light weight proxy on top of the data domain represented by the internals of the database.

This is exactly the nature of APIs. APIs are controlled (proxy) views on the data and capabilities of a domain, optimized for the needs of the API consumer. As long as it is very cheap to create and maintain proxy APIs, such APIs are the means by which you can re-render a domain in multiple forms optimized for each group of API consumers. After all, you probably want to share with external partners a different view of your capabilities than the set of APIs used by your internal developers.

We live in the middle of a perfect storm of change. Originally SOA emerged as a means for shielding the service consumer from changes in the backend. But who protects the service provider from churn in the needs of omni-channel front-end solutions? By applying APIs and services together you can create the eye of calm in the middle of the hurricane of change. Services are the means by which providers codify the base capabilities of their domains. APIs are the way in which those capabilities are re-packaged, productized and shared in an easy to use form. In that fashion, APIs and services are complementary rather than contradictory, and applied together dramatically increase the overall effectiveness of enterprise innovation.

Ready to understand the difference? Try API Connect on Bluemix, it’s free.

Connect with me on @ClausTorpJensen or read my earlier blogs. You can also subscribe to the blog list here

4 comments on"APIs versus Services – what is the difference?"

  1. […] Protect the provider from churn (remember from an earlier blog that defining and deploying new API “views” on existing assets should be easy and […]

  2. […] you just take your services and push them as your first generation of APIs, right? Not so fast. APIs versus Services – what is the difference established that there are fundamental differences between APIs and services. The short version […]

  3. […] not help the service owner control and manage the overall capacity required on a given service. In APIs versus Services I argued that APIs and Services should be independently managed objects. When that is your […]

  4. Well articulated the subtle difference between the services and APIs.

Join The Discussion

Your email address will not be published. Required fields are marked *