Could you please add a docstring which provides a conceptual overview of what's going on here? I'm finding the four nested levels to be really intense. If you could use PEP 257 style, that would be great.

"""Extract ...

<relevant details that might help understand what's going on here>
"""

This many levels of exceptions makes me wonder if there might performance challenges here (because of the cost of going through the exception stack over and over). I don't think it's fair to ask you for a performance test so I'm mostly wondering "out loud" if this is too much exception handling as a way to do control flow. It does feel like a bit of a code smell. Maybe that's the cost of working with a spec that's so dynamic ̄\(ツ)/ ̄

I have added a docstring.

Considering the levels of exceptions I also think this is certainly not ideal but I cannot think of an alternative way to do it though.

For example calling getattr with default argument None wouldn't work, as an attribute could actually be None. Calling hasattr wouldn't make things better either as internally it also does a try-except (https://docs.python.org/3/library/functions.html#hasattr).
It could be argued whether the serializer method case is really needed but otherwise I guess we will need to live with it.

Thanks for thinking about it. The only alternative that I can think of is to have multiple returns. What do you think of something like the following:

 try:
 return getattr(resource_instance, field_name)
 except AttributeError:
 pass
 try:
 # For ManyRelatedFields if `related_name` is not set
 # we need to access `foo_set` from `source`
 return getattr(resource_instance, field.child_relation.source)
 except AttributeError:
 pass
 <and so on...>

Is that any "better?" Or is it worse? It would remove the deep nesting even if the logic is functionally the same.