Skip to main content

Applying Postel’s law in ASP.NET Core–Part II

Yesterday I talked about Postel’s law or the Robustness principle and how it is import in building evolutionary systems. We had a look at how the built-in System.Text.Json serializer handles some scenario's. Today I want to focus on the ASP.NET Core model binding.

What is model binding?

Typically in ASP.NET Core you don’t access the raw HtpContext yourself to extract the JSON from the request body. Instead you let model binders do the hard work.

From the documentation:

Controllers and Razor pages work with data that comes from HTTP requests. For example, route data may provide a record key, and posted form fields may provide values for the properties of the model. Writing code to retrieve each of these values and convert them from strings to .NET types would be tedious and error-prone. Model binding automates this process. The model binding system:

  • Retrieves data from various sources such as route data, form fields, and query strings.
  • Provides the data to controllers and Razor pages in method parameters and public properties.
  • Converts string data to .NET types.
  • Updates properties of complex types.

Tolerant reader

Let’s find out if the Model Binder also behaves as a ‘tolerant reader’. I’ve created a small example controller that expects the same Person DTO as input:

We’ll start with the same use case as in our previous post. We include a Middlename property that doesn’t exist on our model:

This one succeeds. That is also a good start! Let us now check what happens if we forget to include a specific property:

Whoops! This time it fails because it has marked the Lastname field as required. This is because ASP.NET Core doesn’t only do Model Binding but also Model Validation. In this case because  ‘Nullable Reference Types’ are enabled and Lastname is not marked as nullable, we get a validation error.

I updated my model to mark this field as nullable and now the call succeeds:

Let’s try the last one as well and pass a value using an incorrect type. We are passing ‘age’ as a string:

This one succeeds. This is because ASP.NET Core supports type conversions for a range of simple types.

So it turns out that you would think that ASP.NET Core just directly uses the System.Text.Json serializer to parse the JSON request body, instead a lot more things are going on that impact the behaviour.

Popular posts from this blog

XUnit - Assert.Collection

A colleague asked me to take a look at the following code inside a test project: My first guess would be that this code checks that the specified condition(the contains) is true for every element in the list.  This turns out not to be the case. The Assert.Collection expects a list of element inspectors, one for every item in the list. The first inspector is used to check the first item, the second inspector the second item and so on. The number of inspectors should match the number of elements in the list. An example: The behavior I expected could be achieved using the Assert.All method:

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Angular --deploy-url and --base-href

As long you are running your Angular application at a root URL (e.g. ) you don’t need to worry that much about either the ‘--deploy-url’ and ‘--base-href’ parameters. But once you want to serve your Angular application from a server sub folder(e.g. ) these parameters become important. --base-href If you deploy your Angular app to a subfolder, the ‘--base-href’ is important to generate the correct routes. This parameter will update the <base href> tag inside the index.html. For example, if the index.html is on the server at /angularapp/index.html , the base href should be set to <base href="/angularapp/"> . More information: --deploy-url A second parameter that is important is ‘--deploy-url’. This parameter will update the generated url’s for our assets(scripts, css) inside the index.html. To make your assets available at /angularapp/, the deploy url should