We have been doing quite a lot of work in the past Articles, but a part of a code base that actually builds, we haven't seen anything working yet. That will now change in this module, where we are going to create an API that uses our application architecture. Welcome to this module, Adding an API Using ASP.NET Core, where we will be focusing solely on building the API using ASP.NET Core 8. This API will serve as the gateway to the core functionality of our application.
Let's get started. Of course, the way we create the API will also require some thought, and that's really what we will be doing in this module. First things first though, I'm going to create the API project, which will be pretty standard stuff, but I'll give you some pointers here too. What we will be spending more time on is the next part: how are we going to create code in the API? Which code will we really have in our API controllers? I'm going to show you a few options, and we'll see how MediatR comes back into play here. Next, we'll also take a look at which data we will be returning. Finally, to ensure consumers of the API know what functionality it provides, we'll bring in Swagger for API documentation. There’s plenty to do, so let’s dive straight in.
So, as promised, we’ll start by creating the API project, which will be a very straightforward task. Like I said in the intro of this module, we’ve spent a lot of time creating the business functionality using good architectural principles, and we’ve neatly followed Clean Architecture to do so. We have looked at the Core and Infrastructure layers. Here's a diagram again, and we're now going to be adding the next piece of the puzzle, the API.
The API will expose the core functionality to the outside world. The API essentially opens up the backend of our application, allowing various clients to connect and interact with the data and services provided by the core.
From an architectural point of view, the API takes the role of the UI in our layered structure. While we could have built a traditional UI like ASP.NET Core MVC or Razor Pages, we are focusing on creating a clean and flexible API instead. By using an API, we allow our backend to be consumed by various client types—whether it's a web application, mobile application, or even another system that requires programmatic access to our application's features.
But just to be clear, we’ve already built the Core and Infrastructure projects, and these were regular .NET class libraries. Now, I’m going to bring in the ASP.NET Core project for the API.
The API we are creating will be built using ASP.NET Core 8, which ensures we’re using the latest features and optimizations. Even though we are using .NET 8, the structure and general approach remain consistent with other versions, so if you’re familiar with earlier versions, you’ll feel right at home.
In our API application, we need to make some changes to the Program.cs class. Remember that we have already created extensions for the ServiceCollection class in earlier modules. We’ll now use those extensions here since the API will be the executing assembly and the entry point to our application. Of course, we’ll need to use code we’ve already written.
If we follow the architecture schema correctly, we’ll need a reference from our API to the Core project. While that is true, we also need to include a reference to the Infrastructure project. This is necessary due to how the DI container in ASP.NET Core works, as it manages all the external dependencies (like database access, logging, and file exports). If you use a more modular DI container, like Autofac, this wouldn’t be required, but since we’re using the default ASP.NET Core container, these references are essential.
Once the references are set up, the API will interact with the Core logic while leveraging the Infrastructure where needed, creating a clear separation of concerns and adhering to Clean Architecture principles.
Top comments (0)