Skip to main content

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

An important aspect in building robust systems is applying ‘Postel’s law’. Postel's Law was formulated by Jon Postel, an early pioneer of the Internet. The law was really a guideline for creators of software protocols. The idea was that different implementations of the protocol should interoperate. The law is today paraphrased as follows:

Be conservative in what you do, be liberal in what you accept from others.

It is also called the Robustness principle and it is crucial in building evolvable systems. In this post I want to see how this law applies when building ASP.NET Core Web API’s. A typical use case in ASP.NET Core is the following:

  1. A client serializes the model in JSON and sends it over HTTP to our ASP.NET Core server.
  2. On the other side, the server gets the message, extracts the body of the requests and deserializes it back to a model.

It’s this second step specifically I want to focus on, how will ASP.NET Core (or more specifically the System.Text.Json serializer used out of the box) handle the JSON when it receives data it doesn’t expect. Let’s find out!

Remark: In a second post, I’ll have a look at how the ASP.NET Core Model binder handles these scenario’s.

We start a simple example model:

Let’s first see how the serializer handles an unknown property. We include a non existing Middlename property in our JSON input:

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

This test succeeds as well. The Lastname property is set to the default value. OK, let’s try a third one, we provide a different type than expected. Age should be a number and we will provide a string:

This time our test fails with the following exception:

System.Text.Json.JsonException : The JSON value could not be converted to System.String. Path: $.Age | LineNumber: 0 | BytePositionInLine: 32.
---- System.InvalidOperationException : Cannot get the value of a token type 'Number' as a string.

We can see that the JsonSerializer already behaves like a ‘tolerant reader’. It is however possible to further improve this by changing the JsonSerializer behavior through the JsonSerializerOptions. For example we can ignore the propertyname casing by setting the PropertyNameCaseInsensitive value to true:

While writing this post I noticed the .NET 8 announcement where you can further control how missing properties should be handled:

It’s now possible to configure object deserialization behavior, whenever the underlying JSON payload includes properties that cannot be mapped to members of the deserialized POCO type. This can be controlled by setting a JsonUnmappedMemberHandling value, either as an annotation on the POCO type itself, globally on JsonSerializerOptions or programmatically by customizing the JsonTypeInfo contract for the relevant types:

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. www.myangularapp.com ) 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. www.mywebsite.com/angularapp ) 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: https://angular.io/guide/deployment --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