Serializer should be able to specify serializer class.

[yxhuvud]

Currently, the only way to specify what class to use for when serializing a relationship is to give the renderer the class option with a hash with an entry for each serialized resource.

In fast_jsonapi it is possible to specify that for each relationship in the serializer. Sadly, they have no support for polymorphic relationships and doesn't seem to get support for that anytime soon. That

a: It allows specific different views of the same thing, which allow the database layout to be more decoupled from the jsonapi presentation.

b: For users that doesn't think the default lookup path and naming for serializers are good enough, it allows them to not have to repeat every single serializer every single time they have to serialize something.

c: It allows more than one view of the same type of object in the same serialized response.

So I think it would be extremely nice if it was a feature that was supported.

[beauby]

c: It allows more than one view of the same type of object in the same serialized response.

One issue is that it actually allows more than one view of the exact same object. Which one should be in the response document then?

[yxhuvud]

My spontaneous reaction is, if specified on a relationship, use the serializer. Otherwise use the current logic.

Yes, this means an object could be included multiple times, if it has multiple representations that are different but included different ways. I'm not certain if that is a feature or a problem. I suppose it may make the implementation a bit more complicated, though I haven't checked to verify.

I suppose it also would also allow the inclusion of a parent of a node in a tree structure without having to render all parents.

[yxhuvud]

(and FWIW, I think it should be an error if two candidate serializers produce the same value in the type field in the output).

[beauby]

The rationale behind this choice (one serializer per type) is twofold:

1. perfs: each object is serialized only once (the resources graph is first traversed, and then all resources are serialized),
2. clarity: the "serializer defined on relationship" yielded much confusion in AMS as people wouldn't know which serializer was being used and why.

Regarding

a: It allows specific different views of the same thing, which allow the database layout to be more decoupled from the jsonapi presentation.

For that you can have different serializers. You should probably not have different views of the same thing within a given document.

b: For users that doesn't think the default lookup path and naming for serializers are good enough, it allows them to not have to repeat every single serializer every single time they have to serialize something.

One can simply define it once, and possibly write a wrapper (which is what jsonapi-rails does).

c: It allows more than one view of the same type of object in the same serialized response.

That should be avoided IMO.

Sorry for not elaborating more, but I'm quite busy at the moment. Maybe @dawidof has an other opinion?