Understanding the Relationship Between APIs and Microservices.

by Interzoid Team

---

Posted on October 1st, 2019

---

---

It's easy to be confused about the relationship between APIs and Microservices, even for those of us immersed into software development on a daily basis. Let's attempt to clarify it in a simple way.

When terminology is always shifting for similar concepts, sometimes driven by marketing initiatives, the difficulty to understand and explain these technological differences increases. To name a few for passing data across the Web, we have had Remote Procedures Calls (RPCs), Functions-as-a-Service, Web Services, Service-Oriented Architecture (SOA), APIs, and now Microservices as examples of tangential terms that have been part of our Web vernacular over the years.

To better understand APIs and Microservices, the best place to begin is the term Microservice, especially because this is the most recent entrant to the industry lexicon. Generally, it defines an architectural approach rather than a physical "service". The approach consists of a monolithic software application that is broken up into small, loosely-coupled, well-defined components that can be built and managed by different teams at different times. For example, "Register User" could be a Microservice for a Web application that's also utilized within a mobile application or a third-party partner application, and perhaps developed by a user management engineering team in a different geography than the mobile team. The idea is to drastically reduce complexity, dependencies, and development time through well-designed, reusable, granular services.

The Microservices concept does sound similar to SOAs from the previous decade, however many practitioners will insist that Microservices are more fine-grained than SOA-managed services and simplified in context. However, the reality is that SOA is fading from use in favor of the more fresh, market-savvy Microservices term, so to think of them similarly from a conceptual standpoint works fine, especially for the purposes of understanding.

So where do APIs come in? By definition, an API is an interface to an existing application (which might only consist of raw data being served up), accessed typically over the Web with a defined request and response contract, including required input data and the resultant output data. These days, they are usually REST APIs with JSON payloads, including support for them built into almost every programming language. The key point to understand is that the API is one possible interface, and probably the most prevalent, for access to a given Microservice. A Microservice can have zero, one, or multiple APIs providing contractual access to it, and can also have other access points outside of APIs. In other words, the APIs are of interest to developers who want to make use of a specific Microservice. Of course, APIs can provide access to entities other than Microservices.

In a nutshell, that's a way to think about APIs and Microservices and their differences.