What is an API? The short answer is that it’s an acronym for Application Programming Interface – but what does that mean, and how can we use APIs in our Power Platform projects?

APIs provide the mechanism for sharing data and/or functionality across multiple applications. They represent the “business logic” of a solution as opposed to the “user interface” or “front-end” logic.

Let’s consider the canvas apps we built in the previous series of posts. By the end of the third post, we had built an app that was more visually appearing that it was in the second post, but we had issues when the size of the datasets increased. In the fourth post, we introduced the idea of delegation, using Power Automate flows to fetch the data we required rather than having our canvas app filter out the records we needed.

By separating this “business logic” into our Power Automate flows, our canvas app can focus on the “user interface” or “front-end” logic – these items could be developed in parallel if you have many developers building the solution.

Furthermore, the Power Automate flows could be used by other components of our solution, such as another canvas app, model-driven app or even a copilot agent. And so we have enabled the sharing of data and functionality across our applications. To all intents and purposes, we’ve built a rudimentary API already!

Another key benefit to this API approach is the ease of maintenance. Let’s imagine we have to switch from Dataverse to another database, maybe SQL Server. If we had built a suite of apps in the same manner as our first canvas app, we would need to update each one of them to accommodate the new database. However, with the API approach, we would just need to update the Power Automate flows.

Let’s recap the benefits of the API approach:

• Separate business logic from user interface logic.
• Sharing functionality and data across multiple apps and services.
• Easier to maintain.

As mentioned above, we’ve already created our own “first-party” API, interacting with the Dataverse tables in our solution. But what about “third party” APIs – data and services provided by external bodies? How do we integrate those into our solutions?

There are thousands of third party APIs available today for a wide variety of topics (have a look here and here for some examples). Some are free and some require a paid subscription. Data and/or services are made available from HTTP endpoints (i.e. web addresses) – API users make a HTTP request to the API endpoints, and process the HTTP response returned. For the first post in this series, we will create our own third party API using Mockaroo.

In addition to selling vehicles, the sales staff at LaRusso Autos are responsible for searching for and buying vehicles from the open market, which they will refurbish and sell on at a profit. Typically, this means trawling through many different websites for data, but let’s imagine that there is a third-party API which gives the details of vehicles for sale – we’d like to integrate that data feed into our solution.

We’ll look into integration in future posts, but for today we will build a dummy service to outline the basics of APIs.

Pages: 1 2 3 4