This month’s series on building and integrating your HTTP APIs using Web API and lots of other goodies together comes to a close with this post, which will show you some exciting ways your Web API projects and Azure Functions can be integrated in new and exciting ways when you describe them with OpenAPI. In case you haven’t seen the previous posts leading up to this, here’s the list of articles in the Month’o’API series:

• Creating Discoverable HTTP APIs with ASP.NET Core 5 Web API
• Open-source HTTP API packages and tools
• Generating HTTP API clients using Visual Studio Connected Services
• App Building with Azure API Management, Power Apps, and Logic Apps (this post)

The previous posts went deep into how your .NET code could be used to build HTTP APIs and describe their various operations using OpenAPI. Now that we’ve build a well documented HTTP API with .NET and OpenAPI, I’m going to show you how we can leverage that using Azure API Management to light up in Azure Functions, Power Apps, and Logic Apps. Azure API Management is able to use our OpenAPI definition to expose our API endpoints that can be easily consumed in low-code applications. Let me show you how easy it is to do that:

Import your API into Azure API Management

With the release of Visual Studio 2019 16.9, we added support for publishing to existing Azure API Management service instances and creating new Consumption-mode instances of Azure API Management so you can use the monitoring, security, and integration capabilities of API Management if you’re already an Azure customer.

When you’re publishing a .NET Core Web API project to Azure App Service that’s been bootstrapped with Swashbuckle.AspNetCore (on-by-default in ASP.NET Core 5 Web API projects), the API Management tab in the publishing dialog appears. You can select an existing Azure API Management instance, or create a new one.

Once publishing completes, you’ll be able to test the API operations directly in the Azure API Management portal blade. There, you can also monitor traffic, control access, and export the API to other services, covered in the next sections of this article.

Note: Visual Studio only creates Azure API Management instances in Consumption mode. This is a lightweight, serverless version of API Management that is billed by execution, and offers 1 million calls free per month. If you have existing Azure API Management instances, you can import into them, too. The feature is available for any tier of Azure API Management.

If you’re new to Azure API Management, learn more about publishing your APIs into Azure API Management using Visual Studio or Visual Studio Code at docs.microsoft.com.

Build workflows using your APIs with Logic Apps

Once you’ve published your OpenAPI-emitting Web API or Azure Function, both of which are included in the sample repository accompanying this post, they can be used in business workflows, scheduled jobs, or event-triggered processes using Azure Logic Apps. The Logic Apps designer automatically picks up all of the APIs imported into an existing Azure API Management service instance, making it easy to figure out which APIs are available.

Since the Logic Apps designer knows how to paint the various operations exposed by the OpenAPI description for any of my API Management-imported APIs, its easy to figure out which API operation I need to call to create a recurring inventory-checking process.

Extending the workflow with Azure Functions

With the introduction of the OpenAPI extension for Azure Functions, you’ll be able to emit OpenAPI descriptions from your Azure Functions much like you can emit OpenAPI from your Web API controllers using NSwag and Swashbuckle. Included with the sample code, you’ll find a notification Function that builds an Adaptive Card summarizing the inventory status of the low products. Using the OpenAPI extension’s Function attributes, Azure Functions can be described using OpenAPI and imported into Azure API Management, too.

public static class InventoryNotifier
{
    [OpenApiOperation(operationId: nameof(SendLowStockNotification),
      Visibility = OpenApiVisibilityType.Important)
    ]
    [OpenApiRequestBody(contentType: "application/json",
      bodyType: typeof(Product[]),
      Required = true)
    ]
    [FunctionName(nameof(SendLowStockNotification))]
    public static async Task<IActionResult> SendLowStockNotification(
        [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = null)] HttpRequest req,
        ILogger log)
    {
      // function code...
    }
}

Once imported into Azure API Management, the operations this Function exposes can be used in the complex workflows available in Logic Apps. I can mix and match how I use the operations in my store API, built using Web API, with the operations exposed in my Azure Function using a visual workflow designer right in the Azure portal.

Use your APIs to build Power Apps

If you’re building ASP.NET Core Web APIs and Azure Functions in an environment where Office 365 and Power Apps are in use, your HTTP API development skills can be put to good use. API Management APIs can easily be exported to Power Platform as Custom Connectors.

Here, I’ve started building a mobile app that can be distributed to any of the users in my Microsoft 365 tenant. Since I’m just getting started, I’ll quickly add the Custom Connector I just created that connects Power Platform to my API hosted in Azure. Once I add a new Refresh button form, focusing on it will enable the formula bar. There, I can enter in a small bit of code that calls the ClearCollect method within Power Apps to clear a collection variable, productsCollection, then use the StoreAPIs.GetProducts operation to re-populate the collection.

What’s great about Power Apps is that once I run the app to make sure it works, it data-binds even in design mode. So as I work on the app I don’t have to keep re-running it; the data just stays bound to the controls.

Summary

Throughout this series of posts, we’ve taken you on a journey that began with some general guidance on making sure your APIs are well-described using OpenAPI. Then we talked about various open-source packages and tools that make it easier for you to design, build, and test your APIs. As we moved into the latter posts, you’ve seen how those well-described APIs can be used in a variety of app-building and integration scenarios. Hopefully this has shown you some new tricks and tools, and given you some ideas that will make your API and app-building experience more delightful in future projects.

What’s Next?

We’ve had a great time sharing the whole end-to-end .NET HTTP API developer experience with you during this series. We hope you’ve seen that .NET helps you build high quality APIs that integrate well with industry standard specifications, community projects, and Microsoft tools like Visual Studio and Azure.

If you’re new to developing HTTP APIs in .NET, we’ve got an introductory workshop that builds up from REST basics to deployment coming up on February 26th: Let’s Learn .NET: Web API. There’s also a good self-guided tutorial on MS Learn that shows you how to Create a web API with ASP.NET Core step by step.

If you’re a more experienced .NET developer, you can dig into more advanced concepts in the .NET docs, and check out the source code from this blog series.

As always, we’re interested in your feedback. Was the series helpful to you? Would you like to see more targeted series like this, in which we dive deep in a specific area or topic to give you more information? Use the comments below to let us know if you have any feedback.