JSON Opt-in serialization guidelines or recommendation
- Dominant language
- No language data
- Stars
- 4.8k
- Forks
- 6.1k
- Avg merge
- 19h 10m
- Merged PRs (30d)
- 268
Description
**Help us make content visible**
During .NET Framework era, MSDN provides documents about XML serializations, opt-in or opt-out. Typically, for opt-in, the orthodox way is to use DataContractAttribute and DataMemberAttribute.
And for JSON serializations, the orthodox way is to use NewtonSoft.Json.
However, .NET (Core) had built-in JSON serialization through [System.Text.Json](https://learn.microsoft.com/en-us/dotnet/api/system.text.json) and [System.Text.Json.Serialization](https://learn.microsoft.com/en-us/dotnet/api/system.text.json.serialization) which can mostly replace NewtonSoft.Json.
I have googled "c# serialization text json opt in", and have not found Microsoft recommended way of opt-in serialization of JSON.
The closest one is https://github.com/dotnet/runtime/issues/30180, suggested by [layomia](https://github.com/layomia) :
"This can be achieved using DataContractAttribute and DataMemberAttribute, if we provide support for them: https://github.com/dotnet/corefx/issues/38758. We should be careful not to provide too many ways to do the same thing."
And https://github.com/dotnet/runtime/issues/29975 is probably relevant.
**Describe the new article**
- Explain why this article is needed.
During .NET Framework era, MSDN provides documents about XML serializations, opt-in and opt-out. Having similar articles for JSON serialization could be balancing. DataContractAttribute is fine, but we need Microsoft's official position about it for preserving our investments on application coding.
Opt-in is more important for generating client API codes from service codes, since a client code generator generally just extract a portion of POCO classes on the service side, and a portion of a POCO class.
Contributor guide
Assessment
This issue has not been assessed yet.