Investigate replacing `Newtonsoft.Json` with `System.Text.Json`

[basdijkstra]

This might be a good idea as System.Text.Json is built into .NET, whereas Newtonsoft.Json is a third party library.

Even better would be if RestAssured.Net can support both, but that would probably be more work.

See eclipse-tractusx/portal-backend#110 (comment) for the discussion that drives this issue / request.

[basdijkstra]

A big blocker for migrating to System.Text.Json is the lack of support for JSONPath at the moment: dotnet/runtime#31068.

This would make the kinds of verifications and extractions we do in Body() and Extract() very cumbersome, if not unusable.

[basdijkstra]

Given this comment: dotnet/runtime#31068 (comment)

I'm going to close this one for now and stick with Newtonsoft.Json for the time being.

[gregsdennis]

A big blocker for migrating to System.Text.Json is the lack of support for JSONPath at the moment: dotnet/runtime#31068.

I had posted in that issue that I have a fully-compliant (to the upcoming spec) implementation of JSON Path in JsonPath.Net. Did that not work for you?

[basdijkstra]

@gregsdennis thank you for the comment. I don't know if it works or didn't work, because I haven't tried JsonPath.Net. It looks promising.

What's keeping me from making the migration at the moment is that I'd still be using a third-party library, although less of it as the (de-)serialization part can be handled by System.Text.Json itself. Are there any compelling reasons for making the switch, from your perspective?

Also, is there a specific reason there's no 1.0.0 version of JsonPath.Net (yet)? Just curious.

Happy to reopen this for a while.