How to structure your API?
Before jumping to structuring API. Let's understand what is an API.
API is the acronym for Application Programming Interface, which is a software intermediary that allows two applications to talk to each other. Every time you use any app like Facebook, send an instant message or check the weather on your phone, you’re using an API. The beauty of API is the way it can be plugged and played to create some great applications.
API — led connectivity allows you to expand your business with reusable APIs which fills the gap of any monolithic applications.
Creating a good architecture for your API is a mandatory part of the whole API development life-cycle. Now let’s understand how can we better structure our APIs.
While creating an API we can layer our API into three functional layers namely System, Process, and Experience Layer.
This a term many of you might have come across if you are using an API integration tool like MuleSoft. But often what becomes difficult is to understand how to design or create these layers.
The layering of the API can be confusing and often lead to many problems.
Here is what we can follow for a consistent API infrastructure.
- Understand the functional requirement. Don’t jump to development.
- Divide the requirement into simple reusable assets that can exist independently.
- Make use of already existing APIs if that can suffice some of your requirements.
Now the layers:
System APIs:
These APIs are the ones that should be least modified and be as stable as possible. These APIs are ones that should be talking to the end resources like Database, Sales-force, SAP, File-Based storage, etc.
Each APIs made at System Level should be atomic and must be very less coupled to any other. Each should have its own functional existence. These APIs should do the heavy task of CRUD(Create, Read, Update, Delete) operations and should not hold any business logic.
Often we can find a single table having huge data that is not normalized enough. It’s a good approach to functionally divide the columns and create separate System APIs of the same. This will add more atomic nature to your APIs.
Process API:
Once we are done with the basic CRUD operation based System Layer. Next comes the Process Layer. This layer is where you put all the business logic. Use multiple API calls to connect various System APIs and bring a fruitful data integration. This layer acts as butter between the layers of bread.
The beauty of this layer is you can use multi-threading and asynchronous operations to bring data from multiple APIs in less time.
An example:
Let’s consider we have two APIs. One bringing order details and the other bringing account details. So if we want to fetch an order summary of a particular account we can call the two APIs independently if possible and accumulate the response in less time.
Also while inserting data we can call multiple APIs simultaneously and create a faster API service.
A point to note:
The better your System APIs are, the better is the orchestration in your Process level. Dividing the System APIs functionally to exist independently will allow you to call multiple such APIs simultaneously which will enhance your client’s API experience.
This brings us to the last layer which is the,
Experience API:
These are the ones which often changes as per end-user requirement and use the low-level APIs to communicate and fulfill the end-user goals.
The experience APIs are ones that are client-facing and accept the input queries. These queries are then relayed down to the lower APIs which make use of the already present parallel processing based architecture to fetch or insert records.
The takeaway from this?
Understand the business before getting your hands dirty with some code. Break apart the requirement to create a functionally stable independent modules. Combine all those modules for a better and efficient application.
Hope you liked it !
