Introduction
In this article, we are going to look at API and its types with business use cases.
What is API
The API is called as Application Programming Interface which has set of definition, connecting protocol, security, model types and etc., used to expose system to connect external system. As an example, we can see a lot of microservices approaches where each service has its own logic to keep single responsibility pattern.
With this approach, we can containerize, and scale the required API instead of the whole application on our business use case.
Over this API, we have few types, let me look into this as follows,
Open API
The Open API is one which is available for everyone, we can also call this a Public API. Anyone can access, it facilitates engineer team, instead of reinventing the wheel again. For eg., if you want to display weather info in our dashboard, we can use openweatherapi, thats gives requested location weather information for now and next few days based on the request.
Typically the open api gets fund using subscription model, the subscription may be monthly, hit count or etc.,
Private API
The private API is one which not for public, its basically a contract between company to company. Maybe your company wants to do a credit check for your customer, to do that credit check from our system, we will look some good and reliable COTS products who are well known and provide good service. We partner with them so that we get a contract between our premises and their product. If there is any issue from any party to trace issue, it will work well.
Business model on here, we need to pay partner cost, and consumer no need to develop or reinvent anything about expected response. The only option is we need to log our request and response to trace if any issue occurs in the future.
Internal API
The Internal API is a known service that we use in day-to-day activities. For our internal application, we may have different layer and business logic. To segregate our logic into multiple places, we use different microservices, so that the microservices can be consumed by different internal source.
Business Model is to create an ownership principle, each service does only its work, and should not expect multiple works on single API. In other words, we can say it is single responsibility pattern.
Composite API
The composite API is used to get a single response from multiple system. In our use cases, we may want different system response in a single call, so the composite API will accept our request and communicate with different system and get back the whole response. We can also call this as a Facade / Orchestra model.
Business Model for this use case is product team and application team, the product team will facilitate development team.
Thanks for reading this article, hope you learned something new and enjoyed it. Stay tuned will look into another article soon.