I commented on #304 but figured it would be best to flesh out the ideas and propose them separately. By adding two base attributes and an interface we'd gain full control over how responses are deserialized to .NET types.

The first attribute would control the deserialization process from the beginning. (This code is typed into a browser, so don't expect it to compile.)

[AttributeUsage(AttributeTargets.Class)]
public abstract class TypeSerializationAttribute : Attribute
{
    public virtual object Deserialize(Type resultType, HttpResponseMessage message);
}

When it comes time to deserialize you'd look for an attribute on the type that derives from this. If one exists then deserialization is deffered to it, otherwise you'd continue to do JSON deserialization.

Next up is an attribute that would allow you to "post" serialize a value from the response. An example of this would be a HeaderAttribute to parse out a value from the headers.

[AttributeUsage(AttributeTargets.Property)]
public abstract class ValueSerializationAttribute : Attribute
{
   public virtual object Deserialize(PropertyInfo property, HttpResponseMessage message);
}

Finally the interface from the PR would be your final hook into the deserialization process. Given these three hooks there really shouldn't be any restrictions in what you can do to provide custom serialization, and in a manner that's flexible. Just occurred to me (because I was thinking an interface for deserialization would be simpler than the attribute based approach in some cases), you don't really have to supply the interface based hook at all, since an attribute based approach could give this to you just by using a custom attribute. If that approach were used then a PostProcessAttribute would make it easier, even though technically the TypeSerializationAttribute above would be enough.