This has been discussed in a few other issues this week. It seems like it would help to have a place to specifically explore this topic.

Currently the record_type option on relationships is unclear what it does. Does it change the type in the output? Does it affect how the serializer is inferred? Are you supposed to specify the type value? Are you supposed to specify the class name?

Today, it only does one thing: if you want the type in the relationships output to be something other than the property name, you can specify it via record_type. It has no impact on which serializer is being used. If you want to specify the serializer, you need to do that separately with the serializer option.

However, this API interface is error prone: it opens the possibility for the type in the relationships to be different from the fully serialized object's type (in data or includes). It is up to the developer to make sure the record_type matches the serializer's set_type across all relationships.

Once #32 is merged, we will have much better type inference: the relationship will look up the set_type definition on its serializer. This way, the serializer's set_type is the Single Source of Truth: the developer would have one place to define and maintain it.

Once that happens, it seems like there is no reason to maintain record_type. We would take away the ability for a developer to specify a different type than the serializer, but I doubt this is ever desirable since it breaks the JSON:API spec. We would also take away the ability for a relationship to exist without a corresponding serializer, which also seems like this would not happen in the real world, and the workaround is to simply define the serializer.

Therefore I think we can deprecate record_type. It can still be used as is until we decide to remove it in a future major release. Until then it should behave exactly like it does today, and we will output a nice descriptive deprecation warning that explains how to adjust their serializers.

If we receive feedback from the community that people have good reason to continue using it, we can always change our mind and remove the deprecation. But with the lack of clarity and the possibility of introducing invalid JSON:API output, I think we should at least try.

Once we merge #32, I'd be happy to submit a PR for this.