Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abstract / Derived Class Deserialization #200

Open
aariabov opened this issue Sep 22, 2018 · 3 comments
Open

Abstract / Derived Class Deserialization #200

aariabov opened this issue Sep 22, 2018 · 3 comments

Comments

@aariabov
Copy link

Hello. I have model binding problem, like this. Can I make such binding with json api and saule?

@joukevandermaas
Copy link
Owner

It doesn't really seem to fit very nicely in the JSON api spec to do such a thing. Especially since the $type value must be the first value in the object. Perhaps it could work if you create an attribute named $type?

public class MyResource : ApiResource
{
  public MyResource()
  {
    Attribute("$type");
  }
}

then in your payload:

{
  "data": {
    "type": "my-type",
    "attributes": {
      "$type": "MyApp.Api.ConcreteType"
    }
  }
}

I suppose the "recommended" way to do it using JSON API is to set different types for the different subclasses under the data hash.

@PhyberApex
Copy link
Contributor

I came here to ask something very similliar. Right now iirc the "type" parameter sent by the client is not interpreted at all in the deserialization. It would be great if we had a way to do this. ALSO it would be great to be allowed to return multiple APIResources that are derived from each other from a webapi action.

~Cheers

@PhyberApex
Copy link
Contributor

Just came back to tell @aariabov that he probably can make use of the Default settings for the used Newtonsoft serializer. I just added these lines:

JsonConvert.DefaultSettings = () => new JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.Auto,
};

and was able to use derived classed in nested attributes. To use derived classes in top level (ApiResources) would probably require a lot of work on Saule and should be really thought about as it seems to go against the RESTful philosphy and actually would be better suited for RPC.

~Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants