Adding optional trailing_slash for SimpleRouter and test

[decadenza]

Description

For someone it is annoying to have to choose specifically if an API has to have or not the trailing slash. So I added a way to have an optional trailing slash.

This does not break the previous behaviour, where trailing_slash can be only True or False. By default it stays True as before.

There is not an extra option: when trailing_slash=None (or any other value), the trailing_slash becomes optional.
For clarity, we may use something else than None.

Test has been added.

[decadenza]

This is alternative to use a custom class like:

from rest_framework.routers import SimpleRouter

class ExtendedSimpleRouter(SimpleRouter):
    """
    Extends the simple router to add minimum configuration options,
    like optional trailing slash.
    """
    def __init__(self, *args, **kwargs):
        super(ExtendedSimpleRouter, self).__init__()
        self.trailing_slash = "/?"

in our code.

[decadenza]

For clarity, especially in documentation, one may also use:
SimpleRouter(trailing_slash="optional")
with the same effect of None, as the optional trailing slash will be added every time the argument is neither True or False.

[sevdog]

Why having an optional trailing slash (in the regex) and not using the APPEND_SLASH config?

[decadenza]

Hi @sevdog and thank you for replying.

I have an embedded device that sends a POST request to myserver.com/api/endpoint with and without trailing slash.
From the APPEND_SLASH configurations, I quote:

Note that the redirect may cause any data submitted in a POST request to be lost.

So losing the data is the first concern.

Secondly, it is more efficient than having Django constantly performing internal redirects (apart for losing data). The difference in the regex evaluation runtime should be negligible.

See also https://stackoverflow.com/a/46163870/3396785

Any thoughts?

[sevdog]

An other concern is that with this kind of implementation if you have use_regex_path=False it is going to cause problems to other URLs.

You could also achieve the same result by using two routers: one with trailing_slash=True and one with trailing_slash=False.

[sevdog]

An other way to obtain this is to override CommonMiddleware to provide a redirection using HTTP status 308 which tells the client to keep method and body.

[decadenza]

I did not consider the use_regex_path=False situation, but it may be taken into account simply by doing:

if trailing_slash is True:
    self.trailing_slash = '/'
elif trailing_slash is False:
    self.trailing_slash = ''
else:
    if use_regex_path is False:
        self.trailing_slash = "/"         # No regex, no party... Use the trailing slash as default.          
    else:
        self.trailing_slash = "/?"        # Optional trailing slash as before.

Using two routers does not seem DRY.

Not sure about the middleware solution. I think that's more of a Django PR than of this framework.

How would you address this optional trailing slash thing in one of your projects?

[sevdog]

I have an embedded device that sends a POST request to myserver.com/api/endpoint with and without trailing slash.

How would you address this optional trailing slash thing in one of your projects?

This seems to be an issue with the embedded device to me, because /endpoint and /endpoint/ are two dirrefent URIs and the client should be aware of this. If the same device (software) sometimes adds/removes the trailing slash this is a bug in that software.

See also https://stackoverflow.com/q/61547014

This said, this PR is not going to be merged because of current contributing policy because there are ways to make everything work without any change in DRF and this is not a feature of Django.