Development with a Dot

Introduction In this post I'll be talking about JSON serialisation performance using the base JSON classes included in .NET ( System.Text.Json ) as well as what used to be the de facto standard for serialisation, and was even included in the .NET templates,  Newtonsoft.Json . I was curious to find out if there were any big differences in performance between the different APIs. For starters, this is the type and instance that we'll be serialising in these examples: public record Data(int Id, string Name, DateTime Timestamp); var data = new Data(1, "Ricardo", DateTime.Now); Lets start first with  Newtonsoft.Json ! Newtonsoft.Json Newtonsoft.Json  has been around for a while, and it was once the default JSON serialiser for .NET, including .NET Framework and .NET Core. It has lots of features, and the new .NET API  System.Text.Json  hasn't (yet) come close to them. It essentially contains two different serialisers/deserialisers: JsonConvert JsonSerializer The way t...

This is another post on my ASP.NET Core pitfalls series . It is actually related to this one  ASP.NET Core Pitfalls – Null Models in Post Requests . What happens if you try to submit a string containing JSON as a POST? I mean, you always submit strings, but this time you don't want for it to be parsed into some class. Like this: [HttpPost] public IActionResult PostString([FromBody] string json) { ... } You may be surprised to find out that this fails with a HTTP 415 Unsupported Media Type . Now, you might be tempted to add an [Consumes] attribute to it, such as: [HttpPost] [Consumes("application/json")] public IActionResult PostString([FromBody] string json) { ... } And this will actually work! The problem is, or could be, that it requires the sender to send the appropriate Content-Type header (" application/json "). Another, better, solution is to just read the string from the from the request stream: [HttpPost] public IActionResult PostString() { using v...