You've successfully subscribed to WorldRemit Technology Blog
Great! Next, complete checkout for full access to WorldRemit Technology Blog
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info is updated.
Billing info update failed.
.NET Core custom serialization

.NET Core custom serialization

. 3 min read

| Image by Ramon Salinero via Unsplash Copyright-free

While working with Dotnet core Api's out of the box there are a few supported payload types, but these are not extensive and may not always supply the content type we require. In the example we are looking at in this article we had a callback payload from a payout partner that was text/xml.

Now we can have a method with a no parameters and then use the HttpContext stream to read the data from, but this would have to be repeated in every possible endpoint that the partner would call.

To get around this we need to look at what the core libraries are actually doing when turning a request body into parameters to be used within a method body. Under the hood the boot strap checks for any registered classes that implement the InputerFormatter class.

This allows us to be able to hook into this pattern and create our own concrete typed class that will parse the XML we get from the partner and supply to the methods we want.


The above image show the simplicity of creating an implementation, we have a constructor and 2 methods. If we look into the method that does the work for us CanRead


Firstly we have to check we have a context, if not then the client has gone away and we will throw an error. After this all we need to do it check we support this content type within our Formatter, and return true/false. Because there are many formatters here returning false will allow the code to behave as it would have before with a standard Json payload.

Next we have one more method to create ReadRequestBodyAsync this is where we actually read the request stream and return our content to the controller, in our case we only care about giving the controller a string of XML, but we can return a stream, or even a strong typed object here.


With all of these now in place all we need to do is boot strap this into our StartUp so that our controllers can utilities our new InputFormatter. This is done when we call the .AddMvc extension while configuring our services.


We now have the ability to receive any Xml payload and send it to any controller in the same way we would read JSON.


Now we can read XML we also need to be able to send it back to the payout partner as they also want to have XML object returned to them, and again we can make a nice shared class that will return XML from a string, stream or object.

This time we look at overriding the StatusCodeResult as this class has all the underlying logic we need to create a Http payload, but without the correct content or type.


All we need here is to create two overrides ExecuteResult and ExecuteResultAsync after storing the payload in a private variable called _content. We can then write the object to the body of the response and remove any WET coding in the controllers around Serialization and Deserialization