Recently, modern style APIs have become an industry hot topic. Different from old school application programming interfaces, modern APIs are a flexible way of presenting your capabilities to an audience outside of your own team. Imagine an API as a product that you can carefully craft to be attractive to the intended consumer, in hopes of it selling. And if done right, APIs enable enterprises to innovate faster and reach new audiences.

Although modern style APIs are all the buzz, we can’t ignore that, in the past decade, service-oriented architecture (SOA) has also become more mainstream. Both address business and IT concerns alike, so it only makes sense to wonder what the differences are between the two, their approaches to integration, and if you actually need to choose between them.

What is a service

With many different definitions, all with similar concepts, a service can be defined as a logical representation of a repeatable activity that has a specified outcome. Services are self-contained and are a black box to their consumers with a well-defined interaction contract. However, these same characteristics hold true for any well-designed API. In other words, technically, an API is also a service. So, does that mean APIs are just another name for services? While there are many similarities between a service and API, the biggest, most important difference between the two is the objective intended to be achieved with their design.

Service providers versus API consumers

My earlier blog “What is an API and why do I care?” describes the product nature of APIs and the fact that they are inevitably aimed at the needs of a particular group of consumers. Below highlights noteworthy design criteria and the fundamental differences between APIs and the typical concept of a service, as seen from the perspective of the service provider.

To a service provider, the following holds true:

• Reuse means effort to deliver
• Sharing requires effectiveness
• Encapsulation is about less change

However, to an API consumer the following applies:

• Reuse is about speed to deliver, no matter the cost to the provider
• Sharing requires expediency and won’t be used otherwise
• Encapsulation means less to learn, so a complex interface won’t do

These differences often slow down an SOA initiative as conflict arises between service providers and consumers on what constitutes as a good service interface. A mobile developer desires simplicity for their particular app while the backend team wants everyone to use the same standardized service and data model. Could the resolution for this conflict meet both the needs of the developer and backend team without incurring prohibitive cost?

Uniting APIs and services

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 when applied together dramatically increase the overall effectiveness of enterprise innovation.