RestEase.SystemTextJson for .NET 6

[ctorresunimag95]

Hi all,

I found this package for implementing SystemTextJon but it is for .NET 5. I wanted to check if there is anything already implemented for RestEase with systemtext compatible with .net 6 ?

[canton7]

It's fairly easy to write a custom serializer/deserializer for System.Text.Json. This of course doesn't remove the dependency on Json.net.

There are plans to allow making System.Text.Json the default for RestEase 2 and droppind the dependency on Json.net, but it has to be done in a way which maintains backwards compatibility.

[ctorresunimag95]

Got it, yeah my question was to know if there is any plan to allow masking using System.Text.Json as default and drop the dependency on Json.net as in my project I want to just reference Syste.Text.Json.

In the meantime for now I will go with the custom serializer/deserializer.

Thanks!

[hansmbakker]

@canton7

it has to be done in a way which maintains backwards compatibility

Out of curiosity: why is the above assumption there?
Is a major version release not the moment that allows for breaking changes as long as they benefit the product?

[canton7]

There are different levels of breaking backwards compat. Deprecating one way of doing something and replacing it with a similar alternative is irritating but fairly harmless: people just have to see the error, find the new way of doing something, and make the change. Completely changing how something is done conceptually is more annoying, and you risk people just swapping to another library, if that's the same amount of effort and might be more stable.

Doing something like changing the default serializer (with no other indications) is evil: you introduce a subtly breaking change which people might not notice until much later, when they're several hours into debugging one of the problems an incorrectly-serialized payload had caused. That's the sort of breaking change which pisses people off to the point that they move to another library out of spite. That's what I need to avoid at all costs.

So a breaking change is fine, but it needs to be carefully designed such that old code fails to compile in a way which makes the solution discoverable, and the fix makes it clear that they're opting into S.T.J or staying with Json.NET.

E.g. I can't just swap the serializer to S.T.J and let them opt back into Json.NET if they need, and people won't notice that the serializer they're using has changed.

[hansmbakker]

Thank you for the explanation, that was insightful!