Creating a WebAPI End-To-End

In the past couple of months, I’ve been studying about WebAPI and how to create API integration components using this framework from Microsoft. While learning this came also the learning of a lot of good libraries to help me doing a bunch of stuff like the mapping of entities, creating unit tests, integration tests, logging and so on.

In this post and the ones following it, I’ll be doing a series of posts where I will be talking about how to create API Integration components using .Net Core 2.1 and the WebAPI framework from development to deployment in the target environment. I want to cover deployment On-Premises, to Azure using a Web App, and to AKS (Azure Kubernete Services).

The series will be split as:

1. Creating the base WebAPI project; Using the repository pattern; Using AutoMapper to map your DTO’s and repository classes;
2. Deploying your solution to an On-Premises server or to Azure Web App; Implementing logging with App Insights
3. Implementing Unit Testing and Integration Testing with Moq and SpecFlow;
4. Deploying the solution to Azure Kubernete Services;

Create the base WebAPI Project

So, in this first post, I’ll be talking about the creation of the web application itself, the repository classes, the DTO entities and the respective mapping to the responses of the APIs.

You will need a version of Visual Studio to follow along. I’m using Visual Studio 2017 Enterprise, but the Visual Studio 2017 Community edition will work just fine.

In Visual Studio create a new project of type ASP.NET Core Web Application as the picture below shows:

Select .Net Core and ASP.NET Core 2.1 as the framework. In the list of templates choose API with No Authentication and configure for HTTPS.

This will create a project with the structure as below:

I’m going to use Entity Framework to access the database, so we need to create the classes that will access our entities.

Before we go any further, this project I’m creating will store data related to all the championships the football team I’m a huge fan (Sport Club Corinthians Paulista) conquered throughout its lifetime.

In case you don’t know, Corinthians is twice World Champion of Clubs and the last time we won this championship was in December 2012 in Japan against Chelsea F.C. (I was there in Japan watching and following Corinthians by the way).

With that said, we will need 4 entities to hold this data. Team, Federation, Championship and Title. Look at the diagram below to understand the relationships.

Here is the code for the TeamEntity class. Look at my GitHub, to see the implementation of the other entities.

After all the entities are complete, I still need to create the DbContext class, and here is part of the code for that. Again, look for the complete code at my GitHub. Please note that I’m using Entity Framework migrations to create the database with some data as soon as I execute the project, so you need to execute the proper “add-migration MigrationName” using the nuget console.

Repository Pattern

Since I’m looking that my code can be testable and independent from other parts, I will be implementing the repository design pattern.

To do so, I’ll create another folder and create the repository classes that I need. The first one I’m going to create will be responsible to handle the Team entity. To be able to perform unit tests later, I will create an interface and implement that interface in my repository class. By now you know that the complete code is in my GitHub right?

Now that I have all the “database” code done, we can make the calls from the Controller classes. I created one controller for handling the Team entity data as below.

But there’s a problem in this code. The way it’s developed above, I have a dependency in the EF entities, and if I need to change this code later, it will impact my clients which is not a good practice. Let’s see in the next section how we can solve that.

Mapping Entities

In the controller, we don’t want to expose our Entity Framework entities because this would create a dependency between the client of this API with our internal implementation and would make any future change very hard to do since we would have to change all the clients. To avoid this, we need to create separate model classes (DTO Entities) that will represent how the client will interact with this API that is independent of the database implementation we choose internally.

But then, we need to find a way to change the response to use our DTO’s instead of the Entities we received from our database layer. To avoid coding all of that mapping code for every call, AutoMapper comes to our rescue. Instead of coding all this mapping code everywhere, we just need to specify once how the mapping will occur between the EF Entities and the DTO Entities and AutoMapper will handle that for us.

To use AutoMapper, open the nuget manager console, locate the package we want to install and confirm the installation.

After adding the nuget package, we need to add a few lines of code for the mapping itself and the registration of the AutoMapper in our web project. To do so, let’s start with the registration.

Go to the Startup.cs class and in the ConfigureServices method, add the code below:

After that Create a new class deriving from the Profile class that is available in the AutoMapper namespace. Create a mapping from the EF entity to the DTO entity as below:

With the addition of AutoMapper, now the code of the controller class, will be like this:

So, now that all pieces are in place, we can execute the web application and try a few methods to extract the data as below:

Summary

So thats it for the first post of this series. In the next post, I’ll show the deployment options we have for both on-premises environments, as well as a cloud environments. I’ll also talk about logging options.

See you around!!!