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 as something 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 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 searched for a flight 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 tech world, the website’s code talked directly to the database.
Somewhere down the line, “Web 2.0” was here! When the concept of Web 2.0 got popular, all websites wanted to be interconnected to serve customers faster. Say, In our case, a third party website owner contacted the airline’s website and asked 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 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., If could build an API point which is something like:
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 preferred User Interface to their customers.
We could further modify the endpoint as, /getAllFlights?origin&destination.
Now when someone calls this endpoint as:
/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., Accweather.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 some are offered for free. There’s are businesses out there who provide paid services in the form of an API. E.g., Stock markets API.
Various other businesses also mutually exchange API contracts to interconnect their systems to provide a connected solution to their customers.
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.
Say, your phone’s API says- if you need me to shoot an image with the camera, call, and ‘x’ endpoint with few details like shutter speed, delay, etc. And any 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.
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 code and data that help you browse as well as buy products usually are hosted as a single product and interlinked in the code as well.
But say if something goes wrong with the order’s database, your whole system may go down. 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 detailed post explaining microservices in-depth 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 is following 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 and the commitment to team structure, dev-ops procedures the organization is willing to invest in.
When do you use API?
APIs are built to allow its 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.
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 in your next software build? Do let us know in the comments below. :)