ASP.NET Core 7 is an important part of Microsoft's "cloud-first" version called NET 7, which was presented in November. Which was introduced in November. It offers web developers a
range of powerful new tools to create modern web applications. ASP.NET Core 7
is built on the .NET Core runtime and provides all the necessary resources to
build state-of-the-art web user interfaces and reliable back-end services. The
best part is that it supports Windows, Linux, and macOS operating systems,
allowing developers to work across different platforms.
You will find examples of code to help you get started with ASP.NET Core 7 in this article. To
try out the code examples mentioned in this article, you will need to have
Visual Studio 2022 installed on your computer. If you don't already have
it,
you can download Visual Studio 2022 from this link.
Now, let's explore some of the exciting new features in ASP.NET Core
7
Output caching middleware
In ASP.NET Core 7, you can now utilize output caching in all types of
ASP.NET Core applications, including Minimal API, MVC, Razor Pages, and
Web API apps with controllers. To activate the output cache, you must add the output cache middleware to the service collection using the IServiceCollection.AddOutputCache. Additionally, you
can incorporate the middleware into the request processing pipeline by
calling the IApplicationBuilder.UseOutputCache extension method.
To include a caching layer to an endpoint, you can utilize the
following code.
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!").CacheOutput();
app.Run();
Rate-limiting middleware
Controlling the rate at which clients can send requests to endpoints is
a crucial security measure that helps protect web applications from
malicious attacks. By limiting the number of requests from a single IP
address within a specific time frame, you can prevent denial-of-service
attacks and ensure the application's stability. This capability is
commonly known as rate limiting.
In ASP.NET Core 7, you can utilize the
Microsoft.AspNetCore.RateLimiting middleware to enforce rate limiting in
your application. By configuring rate-limiting policies and attaching
them to specific endpoints, you can protect those endpoints from
denial-of-service attacks. This middleware is especially beneficial for
web applications accessible to the public, as they are more prone to
such attacks.
The rate-limiting middleware is compatible with ASP.NET Core Web API,
ASP.NET Core MVC, and ASP.NET Core Minimal API apps. To begin using this
pre-existing middleware, you can add the
Microsoft.AspNetCore.RateLimiting NuGet package to your project. Simply
execute the following command at the Visual Studio command prompt to
include the package.
dotnet add package Microsoft.AspNetCore.RateLimiting
Alternatively, you can include this package in your project by
executing the following command in either the NuGet Package Manager
Console or the console window:
Install-Package Microsoft.AspNetCore.RateLimiting
After installing the rate-limiting middleware, you can add rate
limiting services with the default configuration to your Program.cs
file by including the following code snippet.
builder.Services.AddRateLimiter(options =>
{
});
Request decompression middleware
A new request decompression middleware is introduced in ASP.NET Core 7 to allow endpoints to accept compressed content. This means you no longer have to write explicit code to decompress requests with compressed content. The middleware utilizes the Content-Encoding HTTP header to identify and automatically decompress compressed content within HTTP requests.
When an HTTP request is received that matches the Content-Encoding header value, the request decompression middleware wraps the HttpRequest.Body in an appropriate decompression stream using the corresponding provider. After that, the Content-Encoding header is removed to indicate that the request body is no longer compressed. It's important to note that the request decompression middleware disregards requests that do not have a Content-Encoding header.
The code fragment provided below shows how to activate the decompression of applications for commonly used Content-Encoding types.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRequestDecompression();
var app = builder.Build();
app.UseRequestDecompression();
app.MapPost("/", (HttpRequest httpRequest) => Results.Stream(httpRequest.Body));
app.Run();
The default decompression providers support three compression formats: Brotli, Deflate, and Gzip. These formats correspond to the Content-Encoding header values: br for Brotli, deflate for Deflate, and gzip for Gzip.
Filters in minimal APIs
Filters allow you to run code at specific stages in the request processing pipeline. A filter can run before or after an action method is executed. You can utilize filters to track webpage visits or validate request parameters. By using filters, you can concentrate on the core business logic of your application without needing to write code for handling common concerns across your application.
An endpoint filter allows you to intercept, modify, bypass, or combine cross-cutting concerns like authorization, validation, and exception handling. ASP.NET Core 7 introduces the IEndpointFilter interface, which enables us to create filters and associate them with API endpoints. These filters have the ability to modify request or response objects and can even interrupt the request processing flow. Endpoint filters can be applied to both actions and route endpoints.
The IEndpointFilter interface is part of the Microsoft.AspNetCore.Http namespace, and is defined as follows.
public interface IEndpointFilter
{
ValueTask<object> InvokeAsync(
EndpointFilterInvocationContext context,
EndpointFilterDelegate next);
})
The code snippet below demonstrates how you can combine multiple endpoint filters in a chain
app.MapGet("/", () =>
{
return "Demonstrating multiple endpoint filters.";
})
.AddEndpointFilter(async (endpointFilterInvocationContext, next) =>
{
app.Logger.LogInformation("This is the 1st filter.");
var result = await next(endpointFilterInvocationContext);
return result;
})
.AddEndpointFilter(async (endpointFilterInvocationContext, next) =>
{
app.Logger.LogInformation("This is the 2nd filter.");
var result = await next(endpointFilterInvocationContext);
return result;
})
.AddEndpointFilter(async (endpointFilterInvocationContext, next) =>
{
app.Logger.LogInformation("This is the 3rd Filter.");
var result = await next(endpointFilterInvocationContext);
return result;
});
Typed results in minimal APIs
In .NET 6, the IResult interface was introduced to handle values returned from minimal APIs that don't utilize the built-in JSON serialization for returned objects. It's important to mention that the static Result class is used to create different IResult objects, which represent various types of responses like setting a status code or redirecting the user to a new URL. However, due to the private nature of the framework types returned by these methods, it was challenging to verify the accurate IResult type returned from action methods during unit testing.
In .NET 7, the framework types that implement the IResult interface have been made public. This means that we can now use type assertions when writing our unit tests, as demonstrated in the code snippet below.
[TestClass()]
public class MyDemoApiTests
{
[TestMethod()]
public void MapMyDemoApiTest()
{
var result = _MyDemoApi.GetAllData();
Assert.IsInstanceOfType(result, typeof(Ok<MyDemoModel[]>));
}
In minimal APIs, you can utilize IResult implementation types to perform unit tests on your route handlers. The code snippet provided below demonstrates how this can be done.
var result = (Ok<MyModel&t;)await _MyDemoApi.GetAllData()
If you have liked this blog, please add a comment I will create more blog regarding your requirements
Thank you :)
Comments
Post a Comment