Comprendre le modèle "post / redirect / get"

Question

J'ai beaucoup de mal à comprendre le processus exact de "post/redirect/get".

J'ai parcouru ce site et le Web pendant plusieurs heures et je ne trouve rien d'autre que "voici le concept".

Comment comprendre le modèle post/redirect/get?

Answer 1

Comme vous le savez peut-être d'après votre recherche , POST- redirect -GET ressemble à ceci:

• Le client obtient une page avec un formulaire.
• Le formulaire POSTs au serveur.
• Le serveur effectue l'action, puis redirige vers une autre page.
• Le client suit la redirection.

Par exemple, disons que nous avons cette structure du site Web:

• /posts (affiche une liste de publications et un lien pour "ajouter une publication")
  • /<id> (afficher un message particulier)
  • /create (si demandé avec la méthode GET, renvoie une publication de formulaire à lui-même; s'il s'agit d'une demande POST, crée la publication et redirige vers la /<id> point final)

/posts lui-même n'est pas vraiment pertinent pour ce modèle particulier, donc je vais le laisser de côté.

/posts/<id> pourrait être implémenté comme ceci:

• Recherchez la publication avec cet ID dans la base de données.
• Rendez un modèle avec le contenu de cette publication.

/posts/create pourrait être implémenté comme ceci:

• Si la demande est une demande GET:
  • Affiche un formulaire vide avec la cible définie sur lui-même et la méthode définie sur POST.
• Si la demande est une demande POST:
  • Validez les champs.
  • S'il y a des champs invalides, affichez à nouveau le formulaire avec les erreurs indiquées.
  • Sinon, si tous les champs sont valides:
    • Ajoutez le message à la base de données.
    • Rediriger vers /posts/<id> (où <id> est renvoyé de l'appel à la base de données)

Answer 2

Wikipedia explique cela donc bien!

Le problème

La solution

Answer 3

Je vais essayer de l'expliquer. Peut-être que la perspective différente fait l'affaire pour vous.

Avec PRG, le navigateur finit par faire deux demandes. La première demande est une demande POST et est généralement utilisée pour modifier les données. Le serveur répond avec un en-tête Location dans la réponse et aucun code HTML dans le corps. Cela entraîne la redirection du navigateur vers un nouvelle URL. Le navigateur fait alors une demande GET à la nouvelle URL qui répond avec le contenu HTML que le navigateur rend.

Je vais essayer d'expliquer pourquoi PRG devrait être utilisé. La méthode GET n'est jamais censée modifier les données. Lorsqu'un utilisateur clique sur un lien, le navigateur ou le serveur proxy peut renvoyer une réponse mise en cache et ne pas envoyer la demande au serveur; cela signifie que les données n'ont pas été modifiées lorsque vous vouliez qu'elles soient modifiées. En outre, une demande POST ne doit pas être utilisée pour renvoyer des données, car si l'utilisateur souhaite simplement obtenir une nouvelle copie des données, il est obligé de réexécuter la demande, ce qui rendra la Le serveur modifie à nouveau les données. C'est pourquoi le navigateur vous donnera cette vague boîte de dialogue vous demandant si vous êtes sûr de vouloir renvoyer la demande et éventuellement modifier les données une deuxième fois ou envoyer un e-mail une deuxième fois.

PRG est une combinaison de POST et GET qui utilise chacun pour ce à quoi il est destiné.

Answer 4

C'est une question de concept, il n'y a pas grand-chose à comprendre:

• POST est pour le client d'envoyer des données au serveur
• GET est pour le client de demander des données au serveur

Donc, conceptuellement, il n'y a aucun sens pour le serveur de répondre avec des données de ressource sur une demande POST, c'est pourquoi il y a une redirection vers la (généralement) même ressource qui a été créée/mise à jour Donc, si POST réussit, le serveur pense que le client voudrait récupérer les nouvelles données, l'informant ainsi de faire un GET dessus.