Is your feature request related to a problem? Please describe.
I'm currently maintaining branches of some applications using ASP.NET Core 2.2 + Refit against the ASP.NET Core 3.0 previews.
As the new built-in JSON (de)serialization for 3.0 is still in flux, I'm continuing to use Netwonsoft.Json as the (de)serializer using the new Microsoft.AspNetCore.Mvc.NewtonsoftJson NuGet package and Refit's JsonContentSerializer class.
With updating to 3.0 preview 4, I'm now having to st AllowSynchronousIO to true on both Kestrel and TestServer in order to prevent transient failures from synchronous buffer flushes due to the synchronous nature of the Newtonsoft.Json APIs.
This highlights a need to me to consider transitioning away to the new JSON APIs in System.Text.Json to remove the need to opt-in to synchronous IO in this way.
If not built-in to Refit itself, it would be useful to the community to provide an example of an IContentSerializer (and if/when merged IContentSerializerWithCancellation) implementation that uses the new JSON APIs to enable people to easily get their applications to "keep working" with minimal opt-ins for "discouraged" code usages, such as synchronous IO.
Describe the solution you'd like
Either a NuGet package or documentation on how to use System.Text.Json with Refit.
Describe alternatives you've considered
Describe suggestions on how to achieve the feature
IContentSerializer implementation for System.Text.Json.IContentSerializer implementation using System.Text.Json.I had a quick play around by reverse-engineering the MVC input/output formatters and came up with the below.
public class SystemTextJsonContentSerializer : IContentSerializer
{
public SystemTextJsonContentSerializer(IOptions<JsonOptions> options)
{
SerializerOptions = options.Value.JsonSerializerOptions;
}
private JsonSerializerOptions SerializerOptions { get; }
public async Task<T> DeserializeAsync<T>(HttpContent content)
{
using var stream = await content.ReadAsStreamAsync().ConfigureAwait(false);
return await JsonSerializer.DeserializeAsync<T>(stream, SerializerOptions).ConfigureAwait(false);
}
public Task<HttpContent> SerializeAsync<T>(T item)
{
string json = JsonSerializer.Serialize(item, SerializerOptions);
var content = new StringContent(json, Encoding.UTF8, "application/json");
return Task.FromResult<HttpContent>(content);
}
}
Refit should move away from Json.NET to the new System.Text.Json. Get rid of Json.NET completely.
Given that's quite a new implementation, we'll need to check compatibility with .NET 4.6.1 & Standard 1.4 first, but I'd agree we should consider it.
Get Outlook for Androidhttps://aka.ms/ghei36
From: wrathofodin notifications@github.com
Sent: Friday, June 28, 2019 12:33:02 PM
To: reactiveui/refit
Cc: Subscribed
Subject: Re: [reactiveui/refit] IContentSerializer implementation and/or example for ASP.NET Core 3.0? (#653)
Refit should move away from Json.NET to the new System.Text.Json
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/reactiveui/refit/issues/653?email_source=notifications&email_token=AACOWT3CQGJIVQQMICJ7G43P4XZG5A5CNFSM4HHKA7L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYZ2SSA#issuecomment-506702152, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AACOWT67JCUTEFZIGIWRX2LP4XZG5ANCNFSM4HHKA7LQ.
.NET Standard 1.4 is no longer relevant as .NET Core 1.0 and 1.1 are both out of support now. .NET Standard 2 is our minimum.
Keep in mind that Json.NET is far more flexible than System.Text.Json. The latter is meant for raw perf but the former can adapt to more shapes.
If we go with Sys.Text.Json for the default, we may want to provide an optional package that provides a Json.Net serializer/deserializer as well.
I already have project using System.Text.Json to (de)serialize REST API. Would love to implement Refit, but I would like to not depend on Newtonsoft.Json or change attributes to control serialization of property names.
Resolved by #836
Most helpful comment
Keep in mind that Json.NET is far more flexible than System.Text.Json. The latter is meant for raw perf but the former can adapt to more shapes.
If we go with Sys.Text.Json for the default, we may want to provide an optional package that provides a Json.Net serializer/deserializer as well.