In the past post, we discussed the Web Improvements that have been released in the ASP.NET Core 2.2 preview.
We have discussed how the creation, testing, and documentation of API has been improved in the ASP.NET Core release.
Using Swagger gen, we created API documentation and also able to test our API application from the UI itself.
On successful HTTP action, we usually get 200 status code and response from the API.
ASP.NET Core provides custom error response by default from 2.2 release. The error response includes TraceId to correlate to other response easily,
In the earlier post, we use SwashBuckle to generate swagger UI, but it isn’t able to determine all the possible response type of an HTTP method. For example, a post method can return 200, 400, 500 kinds of responses based on different input.
Our documentation should cover most of the possible response type available in our API.
We shall specify the possible response type of each method in our Controller which will generate related documentation in the Swagger UI. But it will be a tedious process to analyze and add all the methods in our API.
For this, ASP.NET Core 2.2 shipped an API Analyzer that will analyze the API actions and provide code fix that can be added in the code.
We shall the package “Microsoft.AspNetCore.Mvc.Api.Analyzers” from Nuget Package manager
Once added API analyzer in our project, the analyzer starts showing the possible response type suggestion in warning window.
Instead of providing mentioning each response type on every action, we shall globally enable the API convention type with default conventions like below
These DefaultApiConventions can also be extended and defined separately based on our needs.
DefaultApiConventions covers some basic commonly used convention types in APIs.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Based API conventions, now the swagger UI generates documentation of various response types and its sample inputs.
Documentation and testing become simpler in ASP.Net Core 2.2.
Please try out for your API code, and leave your feedback in comment section.
Happy Coding!
On September 2018, .NET Core preview 2 has been released. Dot Net team keeping the Web API improvements as a major theme for this release.
The aim of web API improvements is to make API
Easier to create
Easier test and debug
Easier to document
Easier to consume
Easier to secure
Easier to monitor
API becomes part of a major software application, this release got major improvements to develop APIs and services.
In this post, we shall discuss the improvements made to APIs in terms of creating, debugging and testing.
We can build an API from scratch and let’s view what’s new in this release.
For doing these activities, I’m using Visual studio 2017 preview 2 in my machine. So make sure you are having the similar version to experiment the same.
Create an API Project
Let’s create a new project called “APITest” using the following steps
File -> New Project -> Choose ASP.NET Core Web Application under Web Category
And in the next prompt select ASP.NET Core 2.2 in the topmost drop-down and click.
Now, our API gets created with the default template. We will be having a controller called ValuesController.
Additionally to that, we shall create a new controller called EventController to perform our experiments.
Model
Before creating that controller, let’s create Event model and we can generate our Controller code based on the model we create.
Our Event model will look like below,
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
So, we have our Model ready now. Let’s generate our Controller based on this Model.
Controller
Right click on Controller folder in solution explorer
Select Add
Click Controller
Choose Option “API Controller with actions, using Entity Framework”
Select Model class and DataContext using the plus symbol and Click Add
Once we have clicked the Visual studio will start scaffolding our new controller in a few seconds. And our controller will look like below
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
So, all set with API setup. Whenever we create an API, we will run the application and open the API link in the browser window.
If it is a GET call its fine, but when we need to make POST call or something we need another set of tools to perform testing. In that case, the browser is not the best tool to perform testing in the API.
In .NET Core 2.2, a new tool called HTTP-REPL has been introduced. It’s a .NET Core global which we can install using the dotnet CLI.
HTTP-REPL is a command line tool to interact with API.
Right now, the tool is not shipped with this release. However, we install using the following steps.
How to install HTTP-REPL
Run the following command in command prompt to install in global level in your machine
Once installed, we can verify the installation using the following command
we can run http-repl using the command
dotnet httprepl
And we can point to any API which has swagger enabled to try out by setting the base URL.
Let’s not do that now, we can experiment the tool with the API which we created.
Add HTTP-REPL in Web browser list
Instead of opening the command and traversing to the API URL, we can launch our application into Repl right from our Visual Studio IDE.
For that, we need to add the Repl in the Web browser list.
To Add in web browser list, click browse with the option and click Add and fill the required as follows.
http-repl exe will present in the following path
C:\Users\<>\.dotnet\tools\dotnet-httprepl.exe
Once added, set it as default web browser.
And update your default launchUrl as empty or remove that settings from launchSettings.json
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
As we have added EF in our API, let’s add migration before launching the application.
Run the following command in Package Manager Console (Tools->Nuget Package Manger->Package Manager Console)
Add-Migration Initial
Update-Database
Click F5 or click IIS express in the toolbar to launch
After launching the application, we can test our API endpoint right from our Repl command prompt.
Let’s add Open API spec
To make HTTP Repl more accessible, we can add swagger Open API Spec. So that Repl will get to know the available HTTP methods and info in the application.
Let’s add swagger generation with the help open source project Swashbuckle.AspNetCore
Right click on the project and click Manage Nuget package and install Swashbuckle
Once installed
In the ConfigureServices method of Startup.cs, register the Swagger generator, defining one or more Swagger documents.
Once we have set the default editor, we can make post call as follows by typing command POST
The target editor will default placeholder to fill the data, we can fill up the JSON data, save the file and close it. And also we set header with command line argument -h, the tool got some nice autocomplete feature.
Once closed, the POST call gets called with the data we submit.
Get call
We can make GET call as follows,
Cool! That’s it for now. we can discuss API Analyzer in the next post.