Comment les erreurs côté serveur sont-elles gérées dans le modèle post / redirection / get?

Question

Pour le cas d'utilisation réussi, le flux de travail post / redirection / get (PRG) est assez simple: simplement rediriger (côté client) vers la page souhaitée. Mais qu'en est-il des cas lorsque des erreurs sont rencontrées lors de la validation côté serveur et que nous voulons préserver les entrées lorsque nous affichons à nouveau la page d'entrée?

Pour autant que je sache, il y a deux approches: rendez-vous simplement la page d'entrée après la soumission du post du formulaire (c'est-à-dire pas de redirection) pendant les erreurs (sans tenir compte du modèle PRG); Ou, redirigez vers la page d'entrée et stockez les entrées précédentes quelque part où il peut être récupéré plus tard (par exemple, session), pendant le rendu. Les deux ont des inconvénients: dans le premier, nous sommes présentés avec les problèmes que le modèle PRG nous aide à éviter (par exemple, le signet et la double soumission); La deuxième approche conduit à des objets incohérents (le premier GET trouvera les entrées stockées, les objets ultérieurs pourraient ne pas le faire). Y a-t-il d'autres alternatives à ceux mentionnés ici? J'espère les contributions de la communauté sur la façon dont cette affaire est mieux gérée.

Answer 1

Je le fais généralement la première façon que vous décrivez - redirect uniquement en cas de soumission réussie. Il est difficile de voir un véritable cas d'utilisation pour le signet d'un formulaire contenant des données non valides; D'un autre côté, il est souvent logique de mettre en signet une page de confirmation (après une soumission réussie).

Answer 2

Si l'URL utilisée pour remplir le formulaire est celle auquel le formulaire publie, je ne pense pas qu'il y ait un problème. Si l'entrée est valide, redirigez et obtenez. S'il est invalide, redigez le formulaire rempli. De cette façon, l'interaction ressemble:

GET  /your-url => blank form
POST /your-url (success) => Redirect => GET /success-url
POST /your-url (failure) => filled-in form

Answer 3

The mentioned bookmarkability issue is affecting both approaches, you cannot really bookmark something that relies on some temporary data preserved on the server.

And the double-submission is not really a problem if you ensure that if the validation fails, you don't save any data (i.e. every submission with failed data is idempotent request).

So PRG only on success is a very clean approach.

Answer 4

Like the other answers say, only use Post/Redirect/Get pattern on successful server-side validation. When a form is invalid, just respond to the response directly, with error messages.

For usability, you should make sure that client-side validation is excellent, this is a good idea any way, as users like immediate feedback. Use Javascript, or the new HTML5 form features, such as the required attribute or the maxlength attribute or type="email" attribute and so on.

Of course, you should still have server-side validation for security, and for graceful degradation.

Answer 5

If you are using ASP.NET MVC then there is another method that can be used for the Post -> failure situation. It is covered in #13 of this article: ASP.NET MVC Best Practices (Part 1).

If you implement that method then you can always redirect after a post, even if the post resulted in a failure.