POST (HTTP)

En informática , POST es un método de solicitud compatible con HTTP utilizado por la World Wide Web . Por diseño, el método de solicitud POST solicita que un servidor web acepte los datos incluidos en el cuerpo del mensaje de solicitud, probablemente para almacenarlos. ^{[ 1 ]} Se utiliza a menudo al cargar un archivo o al enviar un formulario web completado .

En cambio, el método de solicitud HTTP GET recupera información del servidor. Como parte de una solicitud GET, se pueden pasar algunos datos en la cadena de consulta de la URL , especificando (por ejemplo) términos de búsqueda, rangos de fechas u otra información que defina la consulta.

Como parte de una solicitud POST, se puede enviar al servidor una cantidad arbitraria de datos de cualquier tipo en el cuerpo del mensaje. Un campo de encabezado de campos en la solicitud POST generalmente indica el tipo de medio de Internet del cuerpo del mensaje.

La World Wide Web y HTTP se basan en varios métodos de solicitud o "verbos", incluidos POST y GET, así como PUT, DELETE y otros. Los navegadores web normalmente solo usan GET y POST, pero las aplicaciones RESTful utilizan muchos de los demás. El lugar de POST en el rango de métodos HTTP es enviar una representación de una nueva entidad de datos al servidor para que se almacene como un nuevo subordinado del recurso identificado por la URI . ^{[ 1 ]} Por ejemplo, para la URI , se podría esperar que las solicitudes POST representen nuevos clientes, cada uno incluyendo su nombre, dirección, detalles de contacto, etc. Los primeros diseñadores de sitios web se alejaron de este concepto original de dos maneras importantes. Primero, no hay ninguna razón técnica para que una URI describa textualmente el recurso web subordinado al que se almacenarán los datos POST. De hecho, a menos que se haga algún esfuerzo, la última parte de una URI probablemente describirá la página de procesamiento de la aplicación web y su tecnología, como . En segundo lugar, dada la limitación natural de la mayoría de los navegadores web a utilizar únicamente los métodos GET o POST, los diseñadores sintieron la necesidad de reutilizar el método POST para realizar muchas otras tareas de envío y gestión de datos, incluida la modificación de los registros existentes y su eliminación.http://example.com/customershttp://example.com/applicationform.php

Los esfuerzos de algunos escritores influyentes para remediar el primer punto comenzaron ya en 1998. ^{[ 2 ]} Los marcos de aplicaciones web como Ruby on Rails y otros facilitan a los diseñadores proporcionar a sus usuarios URL semánticas . Con respecto al segundo punto, es posible usar scripts del lado del cliente o escribir aplicaciones independientes para utilizar los otros métodos HTTP cuando sean relevantes, ^{[ 3 ]} pero fuera de esto, la mayoría de los formularios web que envían o modifican datos del servidor siguen utilizando POST para ese propósito.

Esto no quiere decir que todos los formularios web deban especificarlo method="post"en su etiqueta de apertura . Muchos formularios se utilizan para especificar con mayor precisión la recuperación de información del servidor, sin ninguna intención de alterar la base de datos principal. Los formularios de búsqueda, por ejemplo, son ideales para tenerlo method="get"especificado. ^{[ 4 ]}

Hay ocasiones en que HTTP GET resulta menos adecuado incluso para la recuperación de datos. Un ejemplo de ello es cuando se necesita especificar una gran cantidad de datos en la URL. Los navegadores y servidores web pueden tener límites en la longitud de la URL que pueden manejar sin truncamiento ni errores. La codificación porcentual de caracteres reservados en URLs y cadenas de consulta puede aumentar significativamente su longitud, y si bien Apache HTTP Server puede manejar hasta 4000 caracteres en una URL, ^{[ 5 ]} Microsoft Internet Explorer (que se descontinuó en 2022) está limitado a 2083 caracteres en cualquier URL y una longitud máxima de ruta de 2048 caracteres. ^{[ 6 ]} Del mismo modo, HTTP GET no debe usarse cuando se deba enviar información confidencial, como nombres de usuario y contraseñas, junto con otros datos para que la solicitud se complete. Incluso si se usa HTTPS , lo que impide que los datos sean interceptados en tránsito, es probable que el historial del navegador y los registros del servidor web contengan la URL completa en texto plano, que podría quedar expuesta si alguno de los sistemas es pirateado. En estos casos, se debe utilizar HTTP POST. ^{[ 7 ]}

Cuando un navegador web envía una solicitud POST desde un elemento de formulario web , el tipo de medio de Internet predeterminado es " application/x-www-form-urlencoded ". ^{[ 8 ]} Este es un formato para codificar pares clave-valor con posibles claves duplicadas. Cada par clave-valor está separado por un carácter '&', y cada clave está separada de su valor por un carácter '='. Tanto las claves como los valores se escapan reemplazando los espacios con el carácter '+' y luego usando codificación porcentual en todos los demás caracteres no alfanuméricos . ^{[ 9 ]}

Por ejemplo, los pares clave-valor

Nombre: Liam Wylie Edad: 24 Fórmula: a+b == 21 

están codificados como

Nombre=Liam+Wylie&Edad=24&Fórmula=a%2Bb+%3D%3D+21 

A partir de HTML 4.0, los formularios también pueden enviar datos en formato multipart/form-data, tal como se define en la RFC 2388 (véase también la RFC 1867 para una versión experimental anterior definida como una extensión de HTML 2.0 y mencionada en HTML 3.2).

El caso especial de una solicitud POST a la misma página a la que pertenece el formulario se conoce como postback .

Según RFC 7231, el método POST no es idempotente , lo que significa que varias solicitudes idénticas podrían no tener el mismo efecto que transmitir la solicitud solo una vez. Por lo tanto, POST es adecuado para solicitudes que cambian el estado cada vez que se realizan, por ejemplo, enviar un comentario a una publicación de blog o votar en una encuesta en línea. GET se define como nulipotente , sin efectos secundarios, y las operaciones idempotentes no tienen "efectos secundarios en solicitudes posteriores o futuras". ^{[ 10 ] [ 11 ]} Por esta razón, los rastreadores web como los indexadores de motores de búsqueda normalmente usan los métodos GET y HEAD exclusivamente, para evitar que sus solicitudes automatizadas realicen tales acciones.

Sin embargo, existen razones por las que se utiliza POST incluso para solicitudes idempotentes, especialmente si la solicitud es muy larga. Debido a las restricciones en las URL, la cadena de consulta que genera el método GET puede volverse muy larga, sobre todo debido a la codificación porcentual . ^{[ 10 ]}

• Definición sencilla de POST
• Verbo POST en la especificación HTTP
• «Implementación de almacenamiento en Google Cloud Platform», Guía de estudio para la certificación de Ingeniero Asociado en la Nube de Google Cloud , Wiley, 28 de marzo de 2019, págs. 275–308 , doi : 10.1002/9781119564409.ch12 , ISBN  9781119564409, S2CID 241576882