Microservice vs API: How Are They Different?

API and microservice are two terms that are often used interchangeably in our industry, and because of that, we tend to believe that they’re both the same thing.

But spoiler alert: they’re not.

They’re very close to each other though and that’s the reason for the confusion. They go hand-in-hand, but they’re still different things.

In this article we’ll explore in more detail what exactly an API and a microservice are and how they relate to each other.

So let’s get started!

What exactly is an API?

The acronym API means Application Programming Interface, but as you know, our industry is famous for having really useless acronyms.

I prefer to think of APIs as gateways that connect you to remote logic.

Picture it as a way for your code to have a little conversation with some logic that’s not hanging out locally. That’s why they call it an “interface,” because it’s like a middleman, facilitating the conversation.

In simple terms, APIs are a contract between two parties. I always like to use this analogy for explaining APIs:

Think of your code as a group of hungry customers in a restaurant. All they want is to get their food and eat, right? They couldn’t care less about the cooking process.

Now, behind the scenes, you’ve got the chef and the kitchen crew working their culinary magic. But alone they make no sense, they need someone to serve their food to. In other words: their “service” is meant to be used by others.

But imagine if you, as a customer, had to waltz into the kitchen, place your order, wait for the food to be prepared, and then carry it to your table. I mean, seriously, who does that?

That’s where APIs come in. They allow you to interact with that remote service (AKA the cooks) by simplifying the whole process and shielding you from the nitty-gritty details of that hidden logic. They’re like your personal waiter at the restaurant.

And guess what? APIs aren’t just fancy waiters; they also come with this concept of a “contract.” It’s like a fancy way of saying that this interface is supposed to be standard. So, within this contract, you specify all the rules that will work the same way for everyone using it.

It’s like everyone ordering food from the restaurant will follow the same protocol:

• The channel of communication.
• The list of available features and how to use them.
• The input and output data formats.
• What happens when things go wrong (error conditions and messages).
• Response codes and what they mean.

We could go on and on, but you get the idea. The point is, everyone using the same API gets the same treatment. They’re meant to simplify things by providing a nice abstraction layer.

As a client of an API, you don’t need to worry about what’s happening behind the curtain. All you care about is what the API tells you, and that’s it.

That said, and getting out of the culinary analogy, APIs come in all shapes and sizes.

You’ve probably heard of some of them, like GraphQL and REST. But there are others, more specific and less known ones, like:

• RPC (Remote Procedure Call). It’s like calling up a piece of code (a method or a function) that lives somewhere else, but it feels like it’s right there with you. I even wrote an article on how to create an RPC API using Node.js.
• And then we have SOAP. SOAP stands for Simple Object Access Protocol. It’s a way to execute remote functionalities in a super generic way, using XML to transport information from one place to another. It’s like the wise old grandparent of APIs, still kicking it.

That’s why APIs are such a big deal: they help simplify the connection between systems and save us from a world of unnecessary work. They’re like the superheroes of integration, fighting against chaos and complexity.

What are microservices?

Microservices are basically these little nuggets of logic that are deployed independently and patiently await to be utilized by other systems.

Now, here’s the kicker: users usually don’t directly interact with them. Instead, they rely on other systems that make use of these microservices as their trusty external resources. It’s like a game of telephone, but with code.  

The “micro” part of microservices comes from their aspiration to be smaller and self-contained compared to their bulky cousins, the monolithic services. They’re designed with the Single Responsibility Principle in mind, making sure that the functions they offer are all tightly related to the same topic.

Imagine you have this colossal system that’s constantly communicating with a database because it’s packed with business entities like users, invoices, and delivery routes. Now, you have two options. You could let your code directly talk with the database anywhere it wants within the logic. Or, you could potentially have a dedicated microservice that handles all the database management tasks—storage, retrieval, and whatnot. That way, you’re keeping that monstrous responsibility contained, scalable, maintainable, and adaptable.

And let me tell you, the number one perk of microservices is their Lego-like nature. If built correctly, they become these amazing little bricks that you can reuse and modify individually without throwing the whole system into chaos.

It’s like having your own box of code-building blocks.

But not everything that shines is gold—there’s a catch. Microservices, by their very definition, don’t come with a handy-dandy instruction manual. They don’t have a standardized way of being used. Sure, we’ve figured out some practical standards,  but let’s not get ahead of ourselves.

Microservices can be used in whatever way we see fit. So how can we standardize the way we do it so that others can easily understand how our microservice works? You got it, that’s where APIs come into play!

So are microservices the same thing as APIs?

No, they’re not, but I’m sure you figured out how they fit together by now.

Look at the following architectural diagram for a microservices-based platform:

Here we have a simple scenario where a front-end application is connecting to several microservices (login, data access, user management and invoicing). Some of them are even exchanging data between them (i.e the login service is talking to the data access services, and so on).

If I were to ask you to place the APIs in this diagram, as if they were pieces of a puzzle, where would you put them?

See what I mean? The APIs are the contracts that define how each microservice can be reached, so you can think of the API as a surrounding layer around each microservice.

And mystery solved! Now we can see how microservices and APIs work together.

The difference between microservices vs APIs

Microservices and APIs are not the same, but they have a symbiotic relationship. APIs make no sense without microservices, and microservices are really hard to use without a properly defined API.