With the rise of Microservices terminologies in the IT world, it is often confused with APIs. API, as they are primarily used for, are also perceived as some sort of services that help you exchange data with the systems. Hence the word ‘microservices’ may also confuse most folks to either perceive them as 'APIs' or related to APIs.
However, the core concept of Microservices and APIs are worlds apart. We’ll look at what APIs are, as well as some in-depth reading of microservices and compare the differences.
What is an API?
API is a common term used in and around businesses. However, lots of folks amongst us have a vague understanding of API and what exactly they do.
API stands for “Application Programming Interface”. Now that’s out of sight, let me attempt to explain it to you in a very common layman terms.
Let’s imagine a simple flight booking website, say which belongs to a certain airline. The flight details, booking details, etc are stored somewhere in a system ( also known as database). When you interact with the airline’s website, the website code reads, updates, or deletes some information from or to this database and processes your requests.
When you search for a flight, say for example, from Brooklyn to New York, the website code looked up some info about available flights, prices, promotions, etc from the database and served it to you. Ideally, and in the older world tech, the website’s code talked directly to the database.
Somewhere down the line, “Web 2.0” was formed. With the rise of Web 2.0, websites wanted to be interconnected to serve customers faster. Say, In our case, a third party website owner could contact the airline’s website and ask them to provide him or her with real-time flight data. This way, the third party website could also get customers to the airlines.
Now how would the airline website exchange data with a third party website, and that too on a real-time basis? One option is for the airline’s website to hand over direct access to third party. But wait, is that safe? How do we manage access-rights? And what if more third-party websites are wanting to exchange data in real-time with the airline’s database?
Well, that’s where Application Programming Interface or API comes in to play. We could build an “Interface” to our “Application”, which programmatically will talk to the concerned consumers. The consumer of our API will be optionally handed over some credentials, using which they can read, write, update or delete records in our application.
E.g., We could build an API point which goes something like this:
/getAllFlights
Anyone or anyone’s application who calls this 'Interface' could get the list of all flights and nothing else. All they needed was the data, and our API gave it to them, without delivering the whole airline’s website interface. The API consumer can now take that data and present it as per their preference to their customers.
We could further modify the endpoint as, /getAllFlights?origin&destination.
Now when someone calls this endpoint:
/getAllFlights?origin="Brooklyn"&destination=" New York"
The endpoint will only return flights from Brooklyn and New York.
If you notice, the airline’s company or the provider of API has produced some endpoints for the consumer to consume. The provider of API also included further parameters to the API such as- if you need flights between certain airports, query me with the origin and destination parameters.
The point here is, communications using APIs have to follow certain rules and protocols. This is known as an API contract, where the provider defines, how the consumer should consume its’ services.
With the rise of APIs, lots of companies over the web have open APIs. E.g., Accuweather.com has introduced an API, which you could consume to get the weather for the provided place and then display it on your website or application.
Some APIs are paid, while others are offered for free. There are businesses out there who provide paid services in the form of an API. E.g., Stock markets API.
Businesses may also mutually exchange API contracts to interconnect their systems to provide a connected solution to their customers as apart of partnerships. Example, An insurance provider could exchange its API contracts with a car dealer's website in order to help them sell car insurances.
Now that you have understood the basic usage of an API, let’s dive in further. API is not necessarily an exchange of data.
Our example above showed how the airline industry exchanged real-time data with other consumers.However, when you look at it from a different point of view, APIs are programming interface. What if I told you, your computer or phone could have an API to access certain hardware features.
Example, your phone’s operating system could have an API that says- if you need me to shoot an image with the camera hardware on me, call, an ‘x’ API endpoint with few details like shutter speed, delay, etc and I'll do the job for you. Now any authorised application on your phone could access this API to take advantage of the camera. The application need not worry about how to take a picture, but it is relying on the API to manage the job for it. This helps with the concept of separation of concern in programming.
API is not necessarily meant for exchange of data , but could also be used to carry out some functions.
What are microservices?
Microservices on the other hand is a software architecture pattern, where you break every single feature as a standalone segment.
This tries to keep the features truly independent.
E.g., consider a website where you could browse products and order products. The website has some code that lists the products as well as manage the customer's orders. This code and data that help you browse as well as buy products are usually hosted as a single feature and interlinked in the code. In other words, listing the products as well as managing orders is all interlinked and resides in the same codebase for the website.
But unfortunaely, if something goes wrong with the order’s database, your whole system may go down. In order to avoid this single point of failure, 'Microservices' approach - tries to separate the software in truly independent components.
So the code and data to browse products would be a separate component whereas orders data and code would be a different component.
Do read this highly recommended post explaining microservices concepts to absolute beginners here.
The different components within the microservices could talk to each other using APIs.
The core requirement of Microservices is to have ‘truly independent’ services.
As you can imagine, when a microservices project grows, one would create more and more services to keep them independent than to make the existing services larger and larger.
Microservices v/s API
API is an interface for programs to interact with an application, whereas Microservices is a software architecture style where the software components are broken down and built as smaller independent services.
As we saw above, APIs are interfaces to applications. So, if a component within a software follows microservices architecture pattern, it may use API(s) to exchange data with other independent components.
Thus the concept of API can be used within a Microservices architecture.
When do you use microservices?
The concept of Microservices defines the basics of how one should architect the software code.
If you are building an application where you need few components to be critically reliable or you need to scale only a few components in your software, microservices architecture may help.
Microservices architecture is not ideal for all businesses. It depends on their use cases as well as the efforts required to build them. Commitment to development team structure, dev-ops procedures is also required to efficiently manage a microservices project.
When do you use an API?
APIs are built to allow consumers to consume data or services from the provider. So, if you need to allow access to your selective data, or some functionality to users, either external or internal, you need to look at APIs.
APIs can also be used to exchange data and services between various components of a software that is architected based on microservices strategy.
I hope, this article has cleared any doubts about how microservices are different from API and how and when the concepts are used together. Do consider sharing this article, if you found it helpful.
Would you use microservices architecture or APIs in your next software build?