In this video, we are going to understand about what is this API led connectivity. Till now, what we have done is we understood how to create new applications which contains flows and flows contain orchestration logic to orchestrate with multiple services. So, is mule a perfect product for deploying web applications? No right. Basically it mule application we create flows which contain only orchestration logic, but then without a UI, how is this orchestrator flows useful? Right.

So, basically once we create an application which contains all my orchestrated flows and these flows are not for verification What we need to do is we need to expose our application as an API, maybe as a REST API or a soap API. Let's talk about rest API's. Suppose if you are new application is exposing an API. Now a web application can consume your application as an API, get the data from your mule application. And can it can display the UI. Basically, every mule application whatever we write, we have to expose it as an API so that it can be consumed by some other application.

Now, let us focus on what is this API led connectivity? Let me talk about what is this API connectivity with a practical scenario an example. Let's assume that you're developing an application for an e commerce based application company like Amazon and assume that your company is having all the inventory related data in sa p system inventory management is done through an SA p system and let's assume that you are using Salesforce for customer management and all of your order related details let's assume that you're having them in an e commerce app or e commerce based service right. And assume that some of the customer related details are also present in SAP. So customer related details are present in SAP as well as Salesforce, suppose now this is your back end asset, your organization can I say that this SAP says froze and ecommerce based system which is storing moderated data as an asset to your organization.

Yes, let's assume that your organization has these underlying assets. And one of your business unit came up with a business requirement Hey, we want a web application for seeing the order status in order history okay. So, once there is a requirement from your business, then what a team can be formed, which can develop a web application for this. So, traditionally, if you are if you are not following API led connectivity, you end up doing like this. You develop develop a web application where in this application you may write one service to aggregate customer related data. Aggregate customer related data from two systems one from SAP and from Salesforce because they're having Customer related data in both the systems SAP and Salesforce, then your e commerce system is having order related data, then what you might do is you might end up writing one service, let's say order status service which one which needs the data from the e commerce system.

And also when it is showing order status, it might need some customer related data. So your order status service may fetch the customer related data from this aggregated service. And you might end up writing one more service let's say it is order history. Service it can do is clear for us and this also needs to fetch the order related data is from the e commerce system. And of course it needs to get the customer letter data from the service whatever you have written so Your Business business team came up with such a requirement for a web application, which can show our status and our history. And your team has developed such a web application.

That's fine. You might have delivered this project on time and within your budget. But there are there is no reusability in this. What do I mean by reusability. But a second example, maybe down the line, after six months, the business team has come up with one more requirement, hey, we want this order status and order history to be viewed on a mobile app as well. Right.

But now, in this six months, some of the developers who have developed this web application might have left the organization or maybe that busy with some other work. Now what we ended up is again, developing a separate Rate application with similar kind of services, which is captured only for the mobile apps. Right. So basically, there is no reusability is it? I was not able to reuse these aggregations Service, Auto status service order history service, we end up developing a separate new application. Right, this is one thing.

And one more thing here, your services, which are writing in the web application, need to have the credentials of your organizational assets hard coded in their applications, which is not good. Why should we hard code the credentials of our assets? We don't want to do the credentials of our organizational assets to each and every application or the API. So that is one problem. So what is the solution for this That is nothing but API led connectivity. Let me explain you in detail.

Okay, let's assume that this is my SAP system which is having inventory related data as well as customer related data. And this is my Salesforce system which is airing my customer related data and this is your ecommerce application services, ecommerce asset, which has all related data. Now, the best approach is what if the core IT teams in your organization who is not belonging to any of the business units, when I say core IT team, they are not belonging to any of the business unit and they are responsible for managing the organizational aspects. So, if your core IT team can develop one new application Which interacts with SAP system and expose an API. And again, another mule application, which integrates with Salesforce and expose an API, another application which interacts with e commerce system and expose an API. These API's are talking to your underlying systems right?

We can call these API's as system API's which will talk to the underlying systems. Now, these system API's are developed by the core IT team of your organization who are not belonging to any of the business unit. Right. So somebody who is writing these API's, maybe will be hard coding the credentials to talk to these back end systems, only in these API's. Once the system API's have been developed, let's assume that a business team wants to actually develop a web application for the same use case, what are we discussed? Now the business team, what they can do is they can develop an another API, let's say, aggregate customer related data API, aggregate customers by talking to these two system API's.

One is a sap API and Salesforce API. And it exposes customer related data as an another API. Now, the product and the business team can develop one more API, which can actually consume this aggregate customer API and also the order related API from e commerce system. Let's say this is order History API. This exposes an API. And one more API, let's say order status API, which can integrate internally with this ecommerce with API, and it can get the customer to filter data from the aggregated API.

Now, again, each of this is having some business process orchestration, which contain business logic on how to expose order history, order status, and aggregate customers. This contains business process. So we call these API's as process API's. Now, once these API's are developed, let's assume that your business unit, again, is developing a web application. What this web UI can do, it can consume this process API's, they call it a status and order history and can develop them One UI on top of this process API's. So now, tomorrow if there's a requirement for mobile application, a mobile UI, basically.

So what and the team can develop a mobile UI, just by consuming or reusing these API's. So if you're following this API based approach, both mobile app and web app, both are able to reuse the existing API. So, the development effort can be less. So business logic is used in the process. Yes. And also the process API's need not know how to interact with your system with your ecommerce system or sa p systems.

They always whenever they want to get the data from the organizational assets. They this system API's are reused. Is it And let me enhance Actually, let's assume that this process APS are exposed to multiple customers right. So, what you can do is you can expose this process APS to customer one customer to customer three. So customer to customer three customer one all can actually consume these API's and they can build their own applications. But assume that there is a customer new customer for who actually want to consume the same API, but maybe he wants some additional features or maybe additional properties.

So that means customer four wants a different kind of an experience for the same API's. So in such cases, what we do is a best idea. don't expose the process API's to the end customers develop one more layer called as Experience API. And what you do is you write one more API on top of these API's. And you can export this one Experience API to customer one, customer two, customer three, and mean for another customer customer for since he's having a different experience in since the customer for one summer features, along with the existing features. Maybe we can create one more Experience API, which is actually consuming the process API's and maybe some other process API.

And you can give a different experience to customer for. So basically, even in this case, also we are reusing the process API's. So if you are developing your application using this kind of an approach This is called as API led connectivity. So what you do is for each and every requirement, you develop one API, which is nothing but we can call it as a micro service. So you can have multiple micro services in your system. And your application is connecting these API's and forming an application network.

So in this way, we can create multiple application networks using these API's. So this is called as API led connectivity. And this is encouraged by mule soft and assume that if you are deploying each API on cloud up each API based on the requirement, we can scale it individually at scale horizontally or vertically. So if particular API is getting more hits, we can of course scale only that particular API on cloud, right? So it may API led connectivity has a lot of edge. Advantages basically the usability, scalability individually, etc.

So, we will often criticize this API led connectivity. Now you understood what is API led connectivity. In the next video, we are going to design our API's using the design center will understand more about rambles, how to design your API's and later we'll see how to manage your API's. See you in next video.