post-redirect-get - with - redirect post jquery
¿Cómo se manejan los errores del lado del servidor en el patrón Publicar/Redirigir/Obtener? (5)
Para el caso de uso exitoso, el flujo de trabajo Publicar / Redirigir / Obtener (PRG) es bastante simple: simplemente redirija (del lado del cliente) a la página deseada. Pero, ¿qué pasa con los casos en que se producen errores durante la validación del lado del servidor y queremos conservar las entradas cuando volvemos a mostrar la página de entrada?
Por lo que puedo decir, hay dos enfoques: simplemente vuelva a representar la página de entrada después de la forma de envío POST (es decir, no hay redirección) durante los errores (sin tener en cuenta el patrón PRG); o, redirigir a la página de entrada, y almacenar las entradas anteriores en algún lugar que pueda recuperarse más tarde (por ejemplo, sesión), durante el procesamiento. Ambos tienen inconvenientes: en el primero, se nos presentan los problemas que el patrón de PRG nos ayuda a evitar (p. Ej., Marcabilidad, doble envío); el segundo enfoque conduce a GET inconsistentes (el primer GET encontrará las entradas almacenadas, los GET posteriores podrían no). ¿Hay otras alternativas a las mencionadas aquí? Espero los aportes de la comunidad sobre la mejor manera de manejar este caso.
Como dicen otras respuestas, solo use el patrón Publicar / Redirigir / Obtener en una validación exitosa del lado del servidor. Cuando un formulario no es válido, responda directamente a la respuesta, con mensajes de error.
Para mayor facilidad de uso, debe asegurarse de que la validación del lado del cliente sea excelente , esta es una buena idea, ya que a los usuarios les gustan los comentarios inmediatos. Use Javascript, o las nuevas funciones de formulario HTML5 , como el atributo required o el atributo maxlength o el atributo type="email" y así sucesivamente.
Por supuesto, aún debe tener una validación del lado del servidor para la seguridad y para una degradación elegante.
El problema mencionado de la marcabilidad afecta a ambos enfoques, realmente no puede marcar algo que se basa en algunos datos temporales conservados en el servidor.
Y el envío doble no es realmente un problema si se asegura de que si la validación falla, no guarde 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.
Por lo general, lo hago de la primera manera que describe: redirigir solo en el caso de un envío exitoso. Es difícil ver un caso de uso real para marcar un formulario que contenga datos no válidos; por otro lado, a menudo tiene sentido marcar una página de confirmación (después de un envío exitoso).
Si está utilizando MVC de ASP.NET, entonces hay otro método que puede usarse para la situación de falla - Post. Se trata en el # 13 de este artículo: ASP.NET MVC Best Practices (Parte 1) .
Si implementa ese método, siempre puede redirigir después de una publicación, incluso si la publicación resultó en un error.
Si la URL que se usa para completar el formulario es a la que se envía el formulario, no creo que haya un problema. Si la entrada es válida, redirigir y GET. Si no es válido, vuelva a mostrar el formulario completado. De esta manera, la interacción se ve como:
GET /your-url => blank form
POST /your-url (success) => Redirect => GET /success-url
POST /your-url (failure) => filled-in form