I took some time and now I have a solid thinking that we have to use the related views for related fields.
So, for the above exmaple, it should use a special function ofEntryViewSet instead ofAuthorViewSet'srelated_fields function.
Why?

1. The actual resource we are fetching here is the related resource. It makes more sense to have it's viewset serve the request.
2. We get all querysets, filtering, ordering, pagination, permissions for free (almost, after some modifications).
3. The "parent" resource (author in the example above) is just needed for authentication, and as a reference for related fields.

Currently what I do is this (not optimal and performant, but does the job):

1. Have the related field viewset handle the relation throughas_view, passing thelist for -to-many andretrieve for single objects.
2. Pass in the kwargs ofre_path the parent view class, and whatever else needed for filtering.
3. Inget_queryset, I check if the parent viewset is defined in kwargs, create the viewset, passing proper pk from url arguments, and some other fields, then I doget_object to check permissions, and save the instance for future use if any (could be for making performant queries by select_related the field in the parent request and returning it directly.

This approach has things to consider:

1. Client must pass the resulting queryset inget_queryset to a parent function to execute filtering for relations.
2. Performance of creating a viewset for each related fetch can be a lot.
3. Clients should use another mixin for the relations if the relation resource shouldn't be listed. For example, entryflags shouldn't acceptGET /entry-flags api, but should acceptGET /entry/1/flags.

I'll see if I can clean up the code and have others opinion.

related urls served by a single viewset is a simple way of adding relationships links. It has its limitation though such as no filter support. Also important to note is that this got added later. The idea was to simplify the process of providing relationships links.

BeforeRelationshipView was actually used for related urls and can still be used today. So if you wanna use filters better switch toRelationshipView instead of related urls by a single view set. More configuration is needed but gives you the full power of DRF.

With all the complexity and errors related urls served by a single viewset brought I wondered though whether it was a good idea to include this feature. Or maybe there is a better way of simplifying support of related urls then a need to configure each single relationship individuall per resources as currently done withRelationshipView.

I converted this issue to a discussion so it can be further discussed how to move forward or to leave it as it is.

Issue can be extracted once there is an agreement on how to.