Early static API design decisions for JsonSerializer in System.Text.Json

[nikouu]

I've been looking toward System.Text.Json for utility class design inspiration and I'm keen to understand what went into the early design for the static APIs (i.e. JsonSerializer.*).

Finding early discussions around the static APIs is a bit difficult as this work began in the corefx repo outside of the usual runtime API discussions. Some relevant references I could find include:

• SerializerProgrammingModel.md
• JsonSerializer initial commit
• Announcement to move off Json.NET
• Various runtime System.Text.Json reviews in 2018

Looking way back in Json.NET too didn't seem to yield answers either.

I did find unverifiable answers, often overlapping with general reasoning around static:

1. static is more performant
2. It's a utility class so it should be static
3. System.Text.Json is static to be a familiar API to Json.NET

To sum up: I'd like to know the initial static-making decision behind JsonSerializer.Serialize(), JsonSerializer.Deserialize(), and friends - preferably with references (or from the developers themselves).

[huoyaoyuan]

@eiriktsarpalis

I believe it's more about state. static means no states are preserved. However, JsonSerializer does need to keep some states to materialize the options, so the JsonSerializationOptions needs to be manually preserved. This has caused several problems and #74492 is exploring stateful JsonSerializer instances.

[eiriktsarpalis]

I'd have to defer to @terrajobst and @bartonjs on the original reasons why JsonSerializer exposes static APIs, but I would guess it has something to do with being able to quickly serialize objects into JSON without a lot of ceremony.

[terrajobst]

@eiriktsarpalis is correct: the goal was to minimize ceremony to have simple one-liners. I believe we modeled it off of Newtonsoft.Json's JsonConvert API.

[nikouu]

Fantastic, thank you everyone!