¿Cómo maneja todas las formas en que puede despachar desde un POST HTTP?

Question

Imagine que un usuario acaba de publicar datos en su aplicación web y desea volver a mostrar la página actual con un mensaje sobre su éxito o falla. Esto se complica.

Si los datos son válidos y el usuario espera html, desea emitir un redireccionamiento para que la actualización no los vuelva a publicar. Desea redirigir al referer, si existe, y mostrar un mensaje. Si no están esperando html, simplemente puede devolver 200 OK.

Si los datos no son válidos y el usuario espera html, desea volver a procesar la página de donde provienen, con un error visible, para que puedan volver a publicarse. Para hacer esto, debe ejecutar la acción anterior y avisarle del mensaje de error. Para decidir cuál fue la acción anterior, tal vez la incluyó como un parámetro oculto en el formulario. Si no esperan html, puede devolver un error de cliente 4xx aplicable.

Me encuentro haciendo este tonto baile demasiadas veces. Entonces las preguntas son:

1) ¿Cómo resumiría todo este proceso para que cualquier publicación de formulario pueda aprovecharlo?

2) ¿Cuál es la forma más sostenible o menos repetitiva de lograr esto en su marco web favorito?

3) ¿Hay algo que cambiaría a todo este proceso que lo haría más simple?

Idea 1: Nunca renderizar en una publicación, siempre redirija. Rellene los datos de error en la sesión por una fracción de segundo entre las solicitudes y luego desactívelas, al igual que el mensaje de éxito. De esta forma, las publicaciones válidas y no válidas se pueden gestionar de la misma manera.

Idea 2: No hagas ninguna publicación HTTP normal. Solo usa ajax. Ahora no tiene que preocuparse por renderizar o redireccionar en absoluto. Esto solo sería útil si ya tienes una aplicación ajax-heavy.

Answer 1

Hacer aplicaciones web decentes sin requerir JavaScript es demasiado trabajo. Voy a usar AJAX en estas situaciones.

Answer 2

Idea 2 por la ventana. Esa es una idea horrible y no necesaria en absoluto. AJAX es agradable, pero no exageres. Sin mencionar: ¿qué hay de ese pedazo de usuarios con Javascript deshabilitado?

Creo que lo que estás pensando (sin saberlo realmente) es el patrón Post/Redirect/Get. Es la mejor práctica cuando se trata de esto, y debes seguirlo. Básicamente, como dijiste, nunca responde a un POST por otra cosa que no sea una redirección. En cuanto a las notificaciones, la mayoría de las veces usted sabe de dónde viene debido a la acción en particular. Si no lo hace, el HTTP REFERER es una alternativa decente. Sí, se puede deshabilitar, pero eso es ~ 1% de tus usuarios, si eso. En cuanto a las notificaciones, las sesiones son perfectas para esto. Simplemente almacene el código y el mensaje en la sesión actual y haga que su plantilla sea consciente de ellos. Imprima el mensaje si existe y elimine las variables de sesión.

Answer 3

No hay que avergonzarse al hacer devoluciones de datos y no se puede evitar la devolución de datos porque es la manera más fácil de conservar los datos en las solicitudes HTTP. Eso o parámetros de consulta que es otro viaje de ida y vuelta al servidor por lo que equivale a lo mismo con unos pocos intercambios. No se recomienda usar View state o sessions.

Idealmente, la misma página verificará si la solicitud es una publicación y maneja toda la lógica allí. Por lo tanto, la clave detrás o las páginas de aplicación con formularios tendrán una sección para manejar una publicación.