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