El patrón artículo / 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 determinar marcadores, compartir URLs y recargar un portal web que consulta y envía datos de formularios, sin crear contenido duplicado o casi duplicado.
El patrón PRG es utilizado frecuentemente 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 artículo y conseguir consultas en la versión 1.1 del protocolo HTTP, y puede requerir etiquetas canónicas y marcado de Noindex.
Información general
El motivo para el uso del patrón PRG es la próxima: Cuando se envían datos de formulario mediante 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 usar el patrón PRG para evitar este contenido duplicado. En vez de un portal web con contenido duplicado, se muestra el portal web que se entrega por medio de una solicitud posterior y una redirección.
Cómo funciona
Cuando un cliente llama y rellena un formulario web, normalmente se entrega al servidor mediante 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 existen 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. Posteriormente de la entrada en la base de datos, se envía una redirección al cliente. El cliente inicia entonces una petición de conseguir al servidor, que a su vez envía una página de confirmación. Si el usuario recarga el portal web, sólo se enviará al servidor otra solicitud de get. En vez 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 se trata de 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 conseguir 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: Posteriormente de una solicitud de envío, se entrega al cliente la página web correcta con los datos modificados por medio de la instrucción de redireccionamiento ( HTTP 303).
- GET: El cliente solicita una página de confirmación. Cuando se recarga, esto además se hace sin un cambio en la base de datos y, seguramente, 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 administración de contenidos. Una solución en PHP puede tener el siguiente aspecto: El formulario web se llama echo.php, debe ser causado y el servidor de procesamiento debe soportar el análisis de PHP o utilizar PHP como lenguaje del lado del servidor. En el ejemplo, la primera carga del archivo es lanzada por un usuario que navega al portal 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 mediante de una petición get. Inclusive con otra petición de obtención, la entrada permanece actual, dado que el contenido modificado se retiene a través la sesión. El resultado es un portal web HTML que contiene las entradas pero que llega mediante 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 distintos relacionados con la tecnología del servidor. Los CMS, los lenguajes de programación del lado del servidor y las distintos versiones de PHP o ASP.NET pueden provocar errores y complicar la implementación. Concretamente en el caso de apps 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 argumentos 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 además puede controlarse hasta cierto punto.
Enlaces Web
