¿Cómo se manejan los errores del lado del servidor en el patrón Publicar/Redirigir/Obtener?

Question

Para el caso de uso exitoso, el flujo de trabajo Post/Redirect/Get (PRG) es bastante simple: simplemente redirija (del lado del cliente) a la página deseada. Pero, ¿qué pasa con los casos en los que se encuentran errores durante la validación del lado del servidor y queremos preservar las entradas cuando visualizamos la página de entrada nuevamente?

Por lo que puedo decir, hay dos enfoques: simplemente re-renderizar la página de entrada después del envío del formulario POST (es decir, sin redirección) durante los errores (sin tener en cuenta el patrón PRG); o bien, redirija a la página de entrada y almacene las entradas anteriores en algún lugar donde pueda recuperarlas más tarde (por ejemplo, una sesión), durante el procesamiento. Ambos tienen inconvenientes: en el primero, nos presentan los problemas que el patrón de PRG nos ayuda a evitar (por ejemplo, bookmarkability, double submission); el segundo enfoque conduce a GET inconsistentes (el primer GET encontrará las entradas almacenadas, y es posible que las GET posteriores no lo hagan). ¿Hay otras alternativas a las mencionadas aquí? Espero recibir información de la comunidad sobre cómo se maneja mejor este caso.

Answer 1

Me suelen hacer que la primera manera que usted describe — redirección sólo en el caso de una presentación exitosa. Es difícil ver un caso de uso real para marcar un formulario que contiene datos no válidos; por otro lado, a menudo tiene sentido marcar una página de confirmación (después de enviarla con éxito).

Answer 2

Si la URL que se utiliza para completar el formulario es la que el formulario envía a la POST, no creo que haya un problema. Si la entrada es válida, Redirigir y OBTENER. Si no es válido, vuelva a mostrar el formulario rellenado. De esta manera, la interacción se ve así:

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

Answer 3

Si está utilizando ASP.NET MVC, existe otro método que se puede utilizar para la situación Post -> failure. Está cubierto en el n. ° 13 de este artículo: ASP.NET MVC Best Practices (Part 1).

Si implementa ese método, entonces puede siempre redirigir después de una publicación, incluso si la publicación resultó en un error.

Answer 4

El problema mencionado de bookmarkability está afectando a ambos enfoques, realmente no se puede marcar algo que se basa en algunos datos temporales conservados en el servidor.

Y la doble presentación no es realmente un problema si se asegura de que si la validación falla, no guarda ningún dato (es decir, cada envío con datos fallidos es una solicitud idempotente).

Así que PRG solo en el éxito es un enfoque muy limpio.

Answer 5

Como dicen las otras respuestas, solo use el patrón Publicar/Redirigir/Obtener en la validación exitosa del lado del servidor. Cuando un formulario no es válido, simplemente responda a la respuesta directamente, con mensajes de error.

Para facilidad de uso, debe asegurarse de que validación del lado del cliente es excelente, esta es una buena idea de todas formas, ya que los usuarios reciben comentarios inmediatos. Utilice Javascript o new HTML5 form features, como el atributo required o el atributo maxlength o el atributo type="email", etc.

Por supuesto, aún debe tener la validación del lado del servidor para mayor seguridad y para la degradación elegante.