ASP.NET Core MVC 2.1 will ship with a nice little feature aimed specifically at people building HTTP APIs – ApiControllerAttribute. While the stable release of 2.1 is not yet here, we can already have a look behind the scenes – what is this feature doing, and how can it help you write Web APIs.
When controlling the binding behavior of models in ASP.NET Core MVC applications, it is very common to perform some validation on them. For that, data annotations are a perfect tool.
One of the most typical use cases of data annotations is to ensure that a value of a certain property has been provided by the caller of the API – and this, historically (in “classic” ASP.NET MVC), has been controlled by RequiredAttribute. The attribute can still be used in ASP.NET Core MVC, but there is also a new one – BindRequiredAttribute.
Let’s have a look at the subtle differences between them.
Today I have released the 1.1.0 version of Typed Routing project. I encourage you to try this if you like to have your routes centrally configured, rather than stored in attributes at action level.
You can install it from NuGet using the Strathweb.TypedRouting.AspNetCore package name. Here is what’s new in this release.
A few years ago I blogged about binding parameters from URI in ASP.NET Web API. One of the examples in that post was how to bind a comma-separated collection passed to your API as a query string parameter.
Technologies change, and we now work with ASP.NET Core (and the MVC Core framework), but problems remain the same – so let’s have a look at how we can customize the way parameters are bound from query string in ASP.NET Core MVC.
Some time ago (actually, almost 5 years ago), I blogged about using MessagePack with ASP.NET Web API in order to improve your API’s efficiency over JSON – both in terms of serialization speed and in message payload size.
I recently had a thought – since we now have WebApiContrib.Core for ASP.NET Core, why not revisit the idea, and create a MessagePack add-on for that too?
ASP.NET Core provides a way to constraint parameter values when matching routes via an IRouteConstraint (read more here) interface. This can be very useful, if you want to disambiguate certain routes from one another. This functionality is built into the routing package and is independent from the MVC framework.
However, aside from that, the MVC framework itself also provides an interesting constraint-mechanism – IActionConstraints. Let’s have a look at them today.
In ASP.NET Core, the most common setup is characterized by having a standalone Startup class, responsible for bootstrapping the services needed by your application, as well as setting up the application pipeline.
What most users of ASP.NET Core do not realize, is that at runtime, the Startup instance is actually being resolved from the DI container. This allows you to control some interesting aspects of how your application is bootstrapped, which can be really important i.e. in integration testing scenarios.
Let’s have a look.
The other day I started looking into a problem of being able to run several independent ASP.NET Core pipelines from within the same main application, running on top of the same Kestrel server. This was actually asked on MVC Github repo but closed without a real answer.
Let’s have a detailed look at the problem, and (one) possible solution to it.
Today, let’s have a look at dealing with disposable objects in ASP.NET Core. Imagine you have an object that you’d like to reuse throughout the duration of the HTTP request, but at the end, it must clean up some of its open resources or handles. This is a common requirement for i.e. file writers, DB connections, other unmanaged resources or external processes – to mention just a few.