Thanks for proposing this feature. I think this is mostly related to issue #296 (I guess #178 is a slightly different approach)

I have a feeling such a change should not be added to ResourceRelatedField but to a different field resp. serializer. There is already serializer serializer.HyperlinkedModelSerializer and rest_framework.relations.HyperlinkedRelatedField which according to the documentation on DRF should be used for such a use case. What do you think?

In terms of performance resp. too many sql queries: What I usually do is to use prefetch related data as documented here. Maybe this helps you as well.

Continuing discussion from #296

We cant have 3 Fields like LinksField, DataField, MetaField, and use them separately.

Maybe this would be the best but I am not sure whether there is really a use case for all three fields even though the specification allows it.

I think for now we should stick to the two use cases:

• resource representing all parts (meta, links, data)
• resource only represented as links and optional meta (for better performance)

I've tried to create HyperlinkedRelatedField based on DRF's but came up rewriting same code from ResourceRelatedField about link handling.

What about moving the get_links logic into a mixin? This could then be used from ResourceRelatedField and HyperlinkedRelatedField. If this solves the issue that we do not need to use SkipField and overwriting ManyReleatedField I would certainly prefer it.
As you have tried this in case of deriving from HyperlinkedRelatedField did you still need to overwrite ManyReleatedField field or not?

@sliverc I've tried to implement it in this PR
Current PR looks easier and safer to me.