Minimal APIs are architected to create HTTP APIs with minimal dependencies. They are ideal for microservices and apps that want to include only the minimum files, features, and dependencies in ASP.NET Core.
We would be building a minimal API to retrieve and add todo items using .Net 6
Requirements
- Visual Studio Code
- C# Extension for visual studio code
- .Net 6 SDK
Project Creation
- Open Visual Studio Code Terminal or Command Prompt
- Open the folder where you want to create the project (e.g. cd C:\Users\User\Documents\Projects)
- Run the following command: dotnet new webapi -minimal -o TodoApi
- Open the project in Visual Studio Code
The project template creates a WeatherForecast API with support for Swagger. Swagger is used to generate useful documentation and help pages for web APIs.
Trust the HTTPS development certificate by running the following command:
Select Yes if you agree to trust the development certificate.
Update the generated code
This tutorial focuses on creating a web API, so we'll delete the Swagger code and the WeatherForecast code. Replace the contents of the Program.cs file with the following:
The following code creates a WebApplicationBuilder and a WebApplication with preconfigured defaults:
The following code creates an HTTP GET endpoint / which returns Hello World!:
Add Nugget Packages
NuGet packages must be added to support the database and diagnostics used in this tutorial.
Add the API code
Replace the contents of the Program.cs file with the following code:
The model and database context classes
The sample app contains the following model:
A model is a class that represents data that the app manages. The model for this app is the Todo class.
The sample app also contains the following database context class:
The database context is the main class that coordinates Entity Framework functionality for a data model. This class is created by deriving from the Microsoft.EntityFrameworkCore.DbContext class.
The following code adds the database context to the dependency injection (DI) container and enables displaying database-related exceptions:
The DI container provides access to the database context and other services.
The following code creates an HTTP POST endpoint /todoitems to add data to the in-memory database:
Examine the GET endpoints
Examine the PUT endpoint
The sample app implements a single PUT endpoint using MapPut:
Examine the DELETE endpoint
The sample app implements a single DELETE endpoint using MapDelete:
Prevent over-posting
Currently the sample app exposes the entire Todo object. Production apps typically limit the data that's input and returned using a subset of the model. There are multiple reasons behind this and security is a major one. The subset of a model is usually referred to as a Data Transfer Object (DTO), input model, or view model. DTO is used in this article.
A DTO may be used to:
- Prevent over-posting.
- Hide properties that clients are not supposed to view.
- Omit some properties in order to reduce payload size.
- Flatten object graphs that contain nested objects. Flattened object graphs can be more convenient for clients.
To demonstrate the DTO approach, update the Todo class to include a secret field:
The secret field needs to be hidden from this app, but an administrative app could choose to expose it.
Verify you can post and get the secret field.
Create a DTO model:
Update the code to use TodoItemDTO:
Verify you can't post or get the secret field.
No comments: