plug different JsonSerializer or different SerializationSettings

[luisrudge]

is this possible? From what i saw: no, but i could be wrong.

Do you guys think its worth doing?

We're using refit but we have to serialize stuff with TypeNameHandling.All.

Currently, we're sending just strings and serializing before sending the request
If you guys this is something worth doing, i can try to implement it :)

[anaisbetts]

It's not possible at the moment, not a bad idea for a PR though

[luisrudge]

Which one do you prefer?

Enviado pelo meu Windows Phone

---

From: Paul Bettsmailto:notifications@github.com
Sent: ‎4/‎30/‎2014 12:49 AM
To: paulcbetts/refitmailto:refit@noreply.github.com
Cc: Luís Rudgemailto:luis@luisrudge.net
Subject: Re: [refit] plug different JsonSerializer or different SerializationSettings (#27)

It's not possible at the moment, not a bad idea for a PR though

---

Reply to this email directly or view it on GitHub:
#27 (comment)

[skoon]

If someone had most of this done, hypothetically, and had a method that looked like this

        public IJsonConverter<T> GetJsonConverter<T>()
        {

            return new JsonDotNetConverter<T>();
        }

What method would you prefer for defining the pluggable converters? Right now I'm thinking app.config + Activator, but I could see a case for using Windsor or MEF as a CSL, reading the type to use from app.config, and fetching it from Windsor (defaulting to JSON.Net if no pluggable converter is defined)

Also thinking that the For method could take a "serialize" and "deserialize" Func as overloads rather than tying ReFit to any other JSON serializers, even indirectly.

[anaisbetts]

Right now I'm thinking app.config + Activator, but I could see a case for using Windsor or MEF as a CSL, reading the type to use from app.config, and fetching it from Windsor (defaulting to JSON.Net if no pluggable converter is defined)

Let's not get crazy here.

public static class RefitSettings
{
    public static Func<JsonSettings> GetJsonSettings { get; set; }
}

[skoon]

soooooo

    public class JsonSettings
    {
        public Type JsonConverter{ get; set; }
    }

?

[luisrudge]

No. Let's stay with json.net and just update the settings. :D

[anaisbetts]

@skoon Isn't JsonSettings a built-in class to JSON.Net? It may be called JsonSerializerSettings? Anyways, it's built-in and encapsulates that stuff, including custom converters

[skoon]

Ah, I think there's some crosstalk here. What I'm talking about is plugging in different JSON serializer/deserializers. So using the ServiceStack JSON serializer instead of JSON.net. You guys are talking about just changing the settings/type converters for JSON.Net. Gotcha.

So this became less interesting to me if it's just passing in type converters.

[luisrudge]

That's probably my fault.
I wanted to begin a discussion abouth which one of the alternatives would be the best.
I can see benefits from custom serialization too, but it's way harder to implement and maintain (different nuget packages).

For my problem, custom JsonSerializerSettings will do.
I'll try to implement that.

[anaisbetts]

What I'm talking about is plugging in different JSON serializer/deserializers.

We could do that too, though I'm not as super excited about that.

[bennor]

I was also pretty keen to get this implemented until I discovered it's actually already possible using Json.NET with almost exactly the same approach:

JsonConvert.DefaultSettings = () => new JsonSerializerSettings
{
    // Custom settings...
}

await api.CreateUser(new User()); // Uses custom settings. Just like magic.

The only reason you might need a RefitSettings.GetJsonSettings is if you wanted to isolate it from somewhere else in your app that you are doing JSON serialization and you need to use different settings for the other serialization. Seems like a relatively unlikely edge case to me, but maybe I'm missing something.

No harm in doing it though I guess, but just using the above approach is good enough for the app I'm working on.

I was wondering though if it might be a better idea to implement something like the following:

public static class RefitSettings
{
    public static Func<object, string> SerializeToJson { get; set; }
    // Can't use DeserializeFromJson<T> here because it's a property, 
    /// so the calling code would need to cast.
    public static Func<string, object> DeserializeFromJson { get; set; }
}

That would allow you to plug in a different serializer if you wanted to, which should help @skoon out, and would allow you to isolate the Json.NET settings if you stick with that.

[alexandru-calinoiu]

Anyone want's to pick up on this one?

I like the retrofit approach to this, creating a fluent builder: builder = Refit.Builder().setConverter(converter).setIntercepter(intercepter) and later on use this builder like builder.CreateFor<IApiEndpoint>()

[alexandru-calinoiu]

I've create a pull request with an update test to demo @bennor 's solution #48

[mburbea]

I've created a pull request to take a stab at this issue as well . #80

[bennor]

This was closed by #80.