What's the Difference Between Microservices and APIs?

Last Updated Aug 04, 2023
Emma Jagger

Engineer, maker, Google alumna, CMU grad

Table of Contents:

RESTful APIs revolutionized web development by offering stateless, secure, and standardized data exchange between clients and servers. The old way of "monolith architectures" became restrictive and antiquated. If I wanted a payment service for my app, or Google Maps functionality, my application could call those APIs. The only thing lagging behind was having to write my application in one place, in one programming language without portability. The final nail in the monolithic coffin was containerization. A container is an application with its runtime requirements included in the package. It is like a virtual machine, but much more lightweight. Docker and Kubernetes clusters (containers) could be deployed anywhere, with minimum overhead (and, e.g., Kubernetes monitoring), allowing applications to be "written once and run anywhere." Thus began the age of microservices. Microservices are a web application, but the entire application is broken into many pieces across the cloud. It is an application as a sum of its connections, instead of one piece of software sold in a box. This is called "microservices architecture," vs the old way of "monolithic architecture." This has fundamentally changed what an application is. How are microservices and APIs related? How are they different? This article will discuss the relationship between the two.

Don't reinvent the wheel.
Abstract's APIs are production-ready now.

Abstract's suite of API's are built to save you time. You don't need to be an expert in email validation, IP geolocation, etc. Just focus on writing code that's actually valuable for your app or business, and we'll handle the rest.

Get started for free

What are Microservices?

In the old "monolithic" manner of software development, an application lived in one place, was sold in a box, and support was offered as required. In microservices, we break the component parts down into individual services- microservices- and spin them up as containers in the cloud. A container is an application with its runtime requirements included in the package, like a virtual machine. We then use an API gateway to orchestrate all of these services into a distributed system (service-oriented architecture, or SOA), and accept requests from the front-end client. This part requires rigorous engineering by devops to reduce round trips, decrease latency, and increase API security at public-facing endpoints. It will also require API testing to ensure all of our microservices are operating as a team with load balancing, continuous integration, and continuous delivery. Once we're done, we will have an application that lives across many clusters, with minimal creation of new code on our part. We've just used what already works, and made it work in harmony. It'd probably look like this.

What is an API?

An API, or Application Programming Interface, is a set of rules that define how computers and applications can communicate with each other. If you recall the old switchboards that operators used to field phone calls to their destinations, APIs are a little like that. A client makes an HTTP request to an API at an _endpoint_ which it has access to. The API validates the request and passes the request to the destination server or program. The server sends a response back, first through the API, which then transfers it back to the client.  The API provides security by decoupling the consuming application from the infrastructure providing the service. Once an API service and a client exchange authentication keys, they communicate through the API, meaning they don't have full access to each other, but enough information can be passed to get work done.  

How Do APIs Work?

A client can issue certain kinds of requests (or HTTP "verbs"), of which there are four main types:

  • GET - This request reads information from a record in the database.
  • PUT- This request changes a record's information in the database.  
  • POST - This request creates a new record in the database.  
  • DELETE - This request removes a record from the database.  

We will use IP Geolocation to GET a resource from their API.

Our GET request will retrieve information based on our IP address. We are telling the API with the request header we want all of the content, and it is returned as a JSON file, which is a lightweight text file popular in REST APIs.

In your terminal, enter `curl 'https://ipgeolocation.abstractapi.com/v1/?api_key={YOUR API KEY}'`. You should get output similar to below:

"StatusCode        ":"200StatusDescription":"OKContent          ":{ "ip_address":"", "city":"York", "city_geoname_id":4562407, "region":"Pennsylvania", "region_iso_code":"PA", "region_geoname_id":6254927, "postal_code":"17402", "country":"United                    States", "\"count..."

See the status code of `200`? You have completed your first GET request!

This is how information is exchanged in REST APIs.

Microservices vs APIs

With the use case above, we found the geolocation of an IP with just a GET request to an API. We didn't have to write anything new or reinvent the wheel. Now, imagine a whole application built with APIs- that's what microservices are. If we wanted to build a web sales site, we'd spin up web services for payment, catalogue, and inventory, and orchestrate their interactions via APIs. API contracts define what the API will do and what kind of requests and responses it will issue. So, if a customer finds an item they like in the catalogue (one service), they buy it via the payment microservice (second service), which then tells inventory (third service) that we have one less of that item. We could also build webhooks into this interaction.


Microservices are an architectural style, and they are executed with APIs. Without the interfaces and contracts APIs provide, we'd still be in the monolithic age, with our application in one place. Microservices orchestration is complex, but the advantages are many. One of the biggest advantages to service oriented architecture is scalability. Not only can one service scale independently in cases of high load, agile teams can also work on services separately of each other, then orchestrate them to work together.

4.7/5 stars (11 votes)

Start using one of Abstract's 10+ API's for free today

Get started for free