Separation of JsonApi serialization/deserialization and asp.net core

[ClintGood]

I couldn't see anything related to this. Hopefully I'm not out of line here...
...
It would be helpful to have the code handling the serialization/deserialization of Json:api in a separate .net standard library.

That way, the model, and deserialization could be reused in other, not .net core client projects.

[wisepotato]

Good point! We have already thought about this. First steps have been made with a few previous PRs, but this is very much something we are working on.

[alastairtree]

Worth mentioning that one of these does already exist at https://github.com/codecutout/JsonApiSerializer (used it a fair bit and it works well) although both libraries have some differences in terms of the attributes and types used to achieve the same thing.

[bart-degreed]

Thanks for the link.

[bart-degreed]

In theory, it would be nice to have:

• Pluggable serialization, ie choose between Newtonsoft.Json or System.Text.Json just by referencing another package.
• Extract the resource graph and its serialization into a separate package, so it can be used outside of JADNC.

Unfortunately, things are more complicated. For details, see #664 (comment) and #1028.

We have an annotated object model that goes through the serializer. These objects are annotated with JsonProperty and friends. We also have serialization settings in IJsonApiOptions and various places in the codebase that interact with these, such as determining casing convention and nullability handling. So to make the split, we'd need to abstract all of these features first, then create separate packages that implement the abstraction and delegate to either Newtonsoft or STJ. Now when Newtonsoft or STJ introduces a new setting, we must update our abstractions first before you can use that. This also means we cannot use JsonProperty anywhere, because it has a strong dependency on the serializer. Neither can we duplicate the whole object model per package, because other code depends on it, so it must have a reference to it.

The resource graph is designed for an API server scenario. Attribute capabilities, for example, indicate what an API client is permitted to do. The same applies to CanInclude. The modelling nicely fits (not accidentally) with how EF Core models entities and relationships. In other words, the resource graph isn't very suitable as a general-purpose object modelling tool such as EF Core is. Instead, our resource graph is a thin layer to define how an API server should behave. Dependencies play a role here too: to build the resource graph, we typically scan the underlying EF Core model (although not required). It is quite tricky to unwind these things and it is questionable how useful it will be, given there are various existing serialization libraries available in many programming languages already.