HttpResponseRedirect Vs redirect

Salut la team, est-ce qu'on pourrait utiliser simplement la fonction redirect à la place de HttpResponseRedirect?
par exemple en faisant :
return redirect("signup")quand on a choisi name="signup" pour l'url en question.
Y a-t-il un intérêt à plutôt utiliser HttpResponseRedirect?

merci.
Ali

Salut Ali !

tout d'abord, oui redirect est souvent la manière la plus simple et la plus directe de rediriger l'utilisateur vers une autre page.

L'avantage d'utiliser redirect est qu'il te permet de ne pas te soucier de l'URL ; tu utilises simplement l'identifiant que tu as défini pour cette route. E

Pour HttpResponseRedirect je dirais que c'est plus une méthode si tu as besoin de plus de contrôle sur la redirection, notamment dans des cas où l'URL de redirection n'est pas connue à l'avance ou est construite dynamiquement.

En résumé, redirect est plus haut-niveau, simple à utiliser et suffisant dans la plupart des cas. HttpResponseRedirect est plus basique et offre un contrôle plus fin à un niveau plus bas.

Salut Ali,

J'ajouterais que c'est toujours intéressant quand tu te poses ce genre de questions d'aller voir le code de la fonction (si tu utilises PyCharm, ctrl / cmd + B va t'amener directement à la définition de la fonction).

Pour redirect, tu vois que c'est une fonction très simple de 2 lignes, qui utilise justement HttpResponseRedirect :

def redirect(to, *args, permanent=False, **kwargs):
    """
    Return an HttpResponseRedirect to the appropriate URL for the arguments
    passed.

    The arguments could be:

        * A model: the model's `get_absolute_url()` function will be called.

        * A view name, possibly with arguments: `urls.reverse()` will be used
          to reverse-resolve the name.

        * A URL, which will be used as-is for the redirect location.

    Issues a temporary redirect by default; pass permanent=True to issue a
    permanent redirect.
    """
    redirect_class = (
        HttpResponsePermanentRedirect if permanent else HttpResponseRedirect
    )
    return redirect_class(resolve_url(to, *args, **kwargs))

Avec en prime, l'utilisation comme le mentionnait PA de resolve_url qui fait que tu peux passer le nom de l'URL pour garder quelque chose de dynamique :

def resolve_url(to, *args, **kwargs):
    """
    Return a URL appropriate for the arguments passed.

    The arguments could be:

        * A model: the model's `get_absolute_url()` function will be called.

        * A view name, possibly with arguments: `urls.reverse()` will be used
          to reverse-resolve the name.

        * A URL, which will be returned as-is.
    """
    # If it's a model, use get_absolute_url()
    if hasattr(to, "get_absolute_url"):
        return to.get_absolute_url()

    if isinstance(to, Promise):
        # Expand the lazy instance, as it can cause issues when it is passed
        # further to some Python functions like urlparse.
        to = str(to)

    # Handle relative URLs
    if isinstance(to, str) and to.startswith(("./", "../")):
        return to

    # Next try a reverse URL resolution.
    try:
        return reverse(to, args=args, kwargs=kwargs)
    except NoReverseMatch:
        # If this is a callable, re-raise.
        if callable(to):
            raise
        # If this doesn't "feel" like a URL, re-raise.
        if "/" not in to and "." not in to:
            raise

    # Finally, fall back and assume it's a URL
    return to

L'avantage est donc de te permettre de faire comme dans les templates avec {% url 'mon-url' %} et d'avoir tout qui continue de fonctionner si jamais tu changes la forme d'une URL (sans changer son nom).

superbe merci messieurs! effectivement Thibault c'est super instructif d'aller voir comment ça se passe en "coulisses", on y apprend beaucoup et je pense que c'est un passage obligé (même si beaucoup de choses restent encore obscures :-D)