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:
- A client serializes the model in JSON and sends it over HTTP to our ASP.NET Core server.
- 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: