The reverse(…)
[Django-doc]
and redirect(…)
[Django-doc]
functions are different for a number of reasons. The
first one is that reverse(…)
returns a
string that is the path to visit the
view with the given name (and optional URL parameters).
redirect(…)
on the other hand returns a HttpResponseRedirect
object [Django-doc]. This object can be
returned by the view as HTTP response. If the browser
did not use Ajax or some other asynchronous tool, this
HTTP response will normally trigger the browser to visit
the page specified in the HTTP response. Since certain
redirects can be permanent, redirect(…)
also has a special parameter permanent=…
such that redirect(…)
will return a
HttpResponseRedirect
in case
permanent=False
which is the default, or a
HttpResponsePermanentRedirect
[Django-doc]
for permanent=True
. In case the redirect is
permanent, the browser can cache the redirect, and might
not bother the webserver anymore by visiting the view
that returned the permanent redirect earlier.
Another difference is that the
reverse(…)
uses two parameters
args=…
and kwargs=…
to fill in
the values for the URL parameters. This is
different for redirect(…)
where one passes
the positional and named parameters just as positional
and named parameters. This thus means that we call
redirect('some_view',
some_parameter,
name=other_parameter)
, we get a
HttpResponseRedirect
object with as path,
the string that we can obtain by calling
reverse('some_view',
args=(some_parameter,), kwargs={'name':
other_parameter})
.
A redirect(…)
does not per se works with
a view name. Indeed, if you pass a URL to the
redirect(…)
function, like
redirect('/foo/bar/qux/')
, it will
construct a HttpResponseRedirect
that
redirects to the given URL /foo/bar/qux
, it
will fail to find a view with that name and thus
fallback on a HTTP redirect response with the given
path. This is different for reverse(…)
that
only constructs URLs based on the name of the view, and
its parameters. If no such parameter can be found, the
reverse(…)
function will raise a NoReverseMatch
exception [Django-doc].
Finally redirect(…)
also accepts a model
object that has a .get_absolute_url()
method [Django-doc]. In case one passes
such model as first parameter, it will return a HTTP
redirect response that redirects the browser to the URL
constructed by that .get_absolute_url()
method.
Sometimes programmers write
redirect(reverse('some_view',
kwargs={'some_parameter''='some_value'}))
.
This makes not much sense: redirect
indeed
will generate a redirect response if it is given a URL,
but we can omit the reverse(…)
call and
work with redirect('some_view',
some_parameter='some_value')
.
Summary
reverse(…) | redirect(…) | |
---|---|---|
Return type | str ing | HttpResponseRedirect
or HttpResponsePermanentRedirect |
URL parameters | through
args=… and kwargs=… | positional and named parameters |
Input possibilities | only the name of the view | the name of the view, a
model object with .get_absolute_url(…) , or
a URL/path as input. |