El patrón post / redirect / get o patrón PRG es un enfoque de desarrollo que evita la duplicación de contenido al enviar formularios y proporciona una interfaz de usuario más intuitiva. El patrón post-redirect-get te permite establecer marcadores, compartir URLs y recargar un sitio web que consulta y envía datos de formularios, sin crear contenido duplicado o casi duplicado.

El patrón PRG es utilizado a menudo por las grandes tiendas online para permitir la limitación de productos y categorías de productos con navegación por facetas y reducir el presupuesto del crawl. Desde el punto de vista del diseño web y el SEO, se recomienda el patrón PRG para evitar la duplicación de contenido, proporcionar URLs divididas y conservar los recursos del crawl. La implementación de este enfoque de desarrollo requiere conocimiento del post y obtener consultas en la versión 1.1 del protocolo HTTP, y puede requerir etiquetas canónicas y marcado de Noindex.

Información general

La razón para el uso del patrón PRG es la siguiente: Cuando se envían datos de formulario a través de una solicitud de correo HTTP, esta solicitud puede enviarse al servidor varias veces si el usuario que envía la solicitud vuelve a cargar el formulario con el botón F5 o recargar. Como resultado, los formularios web o pedidos pueden terminar siendo enviados dos veces. Se puede utilizar el patrón PRG para evitar este contenido duplicado. En lugar de un sitio web con contenido duplicado, se muestra el sitio web que se entrega mediante una solicitud posterior y una redirección.

Cómo funciona

Cuando un cliente llama y rellena un formulario web, normalmente se entrega al servidor a través de una solicitud de correo. El servidor realiza un cambio en la base de datos e introduce la información desde el formulario web. Normalmente, el servidor enviará una página de confirmación al cliente. Si hay errores o entradas no válidas, se mostrará un formulario web, que indica estos errores al usuario. A continuación, el usuario corrige los datos y hace clic en Enviar. Los datos correctos se envían al servidor. Si el usuario recarga el formulario web ahora, se creará otra transferencia de datos indeseable de dos entradas desde la base de datos.

Aquí es donde entra en juego el patrón PRG. Después de la entrada en la base de datos, se envía una redirección al cliente. El cliente inicia entonces una petición de obtener al servidor, que a su vez envía una página de confirmación. Si el usuario recarga el sitio web, sólo se enviará al servidor otra solicitud de get. En lugar de un cambio en la base de datos con la post-solicitud, al usuario se le mostrará la página de confirmación. Su solicitud ya ha sido cumplida y la recarga del formulario web no da lugar a la duplicación de contenidos.

El patrón PRG consiste en dos peticiones HTTP y una redirección que hace referencia a los resultados modificados. El patrón permite el procesamiento semánticamente correcto de los mensajes y obtener peticiones en el protocolo HTTP 1.1:

• POST: Se envía un formulario al servidor con una post-solicitud y se cambia una entrada en la base de datos.
• Redirect: Después de una solicitud de envío, se entrega al cliente la página web correcta con los datos modificados mediante la instrucción de redireccionamiento ( HTTP 303).
• GET: El cliente solicita una página de confirmación. Cuando se recarga, esto también se hace sin un cambio en la base de datos y, posiblemente, sin duplicar el contenido resultante.

Relevancia práctica

En la práctica, la implementación del patrón PRG depende del lenguaje de programación utilizado en el lado del servidor y del sistema de gestión de contenidos. Una solución en PHP puede tener el siguiente aspecto: El formulario web se llama echo.php, debe ser generado y el servidor de procesamiento debe soportar el análisis de PHP o usar PHP como lenguaje del lado del servidor. En el ejemplo, la primera carga del archivo es lanzada por un usuario que navega al sitio web www.ejemplo.com/hecho.php. Se muestra el HTML del archivo. El usuario introduce los datos y pulsa Intro. La entrada se envía al servidor como un cambio de base de datos y se entrega al cliente a través de una petición get. Incluso con otra petición de obtención, la entrada permanece actual, ya que el contenido modificado se retiene por medio de la sesión. El resultado es un sitio web HTML que contiene las entradas pero que llega a través de una petición de obtención y no crea contenido duplicado debido a otra petición de publicación.

<?php
    session_start();

    $echoedShout = "";

    if(count($_POST) > 0) {
        $_SESSION['shout'] = $_POST['shout'];

        header("HTTP/1.1 303 See Other");
        header("Location: http://$_SERVER[HTTP_HOST]/echo.php");
        die();
    }
    else if (isset($_SESSION['shout'])){
        $echoedShout = $_SESSION['shout'];

        /*
            The source code which changes the database goes here.
        */

        session_unset();
        session_destroy();
    }
?>

<!DOCTYPE html>
<html>
<head><title>PRG pattern example in PHP</title>

<body>
    <?php echo "<p>$echoedShout</p>" ?>
    <form action="echo.php" method="POST">
        <input type="text" name="shout" value="" />
    </form>
</body>
</html>

[1]

Relevancia para la optimización de motores de búsqueda

El patrón PRG es recomendado por diseñadores web y SEOs en ciertos casos. En detalle, la implementación depende de muchos factores diferentes relacionados con la tecnología del servidor. Los CMS, los lenguajes de programación del lado del servidor y las diferentes versiones de PHP o ASP.NET pueden provocar errores y complicar la implementación. Particularmente en el caso de aplicaciones como la navegación por filtros, se debe tener cuidado de qué recursos se muestran a los usuarios y a los motores de búsqueda. En casos individuales, las etiquetas canónicas, las instrucciones de noindex, y los fundamentos de SEO, tales como URLs habladas, pueden ser utilizados para la implementación impecable del patrón PRG. En el caso de la navegación por filtros, el presupuesto de rastreo también puede controlarse hasta cierto punto.

Referencias

[1]