ModelSerializer.build_url_field should take in account the url namespace.

[lucifurtun]

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

Add some simple DRF urls but namespaced, like:

url(r'^api/', include('api.urls', namespace='api'))

Expected behavior

When using HyperlinkedModelSerializer, I would expect for url namespace to be handled automatically.

Actual behavior

HyperlinkedModelSerializer is building the related url without namespace. The url is simply built from model name (%(model_name)s-detail). In this way, a namespaced url can't be resolved.

[rpkilby]

Thanks for the report @lucifurtun. I've started #5609, which would potentially address this.

[carltongibson]

Hi @lucifurtun.

This is a known limitation I'm afraid. I'm going to close it as out of scope as it stands. (Maybe we come back to this in the future, but it's a long-standing difficulty.)

Without setting the view_name on an explicitly defined url field, or via extra_kwargs, there's not really a way to get the name spacing info down to the serialiser.

If you think about the layers of your app, it goes something like this, with each layer making use of the layer below:

Models <-- Serialisers <-- Views <-- URL Routing

Namespaces apply only at the top URL Routing level, but serialisers, being two-levels below, have no access to that.

In your own app your can find ways of passing the required namespace info down to your serialiser, maybe via the serialiser context or such, but this isn't something we have a clean solution for, even after much time.

Of course, we're always interested in seeing potential solutions/improvements in the form of PRs.

Sorry I can't say more of help.