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, muy probablemente para almacenarlos. A menudo se usa al cargar un archivo o al enviar un formulario web completo.

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

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

Publicación de datos

La World Wide Web y HTTP se basan en una serie de métodos de solicitud o 'verbos', incluidos POST y GET, así como PUT, DELETE y varios otros. Los navegadores web normalmente usan solo GET y POST, pero las aplicaciones en línea RESTful usan muchos de los otros. 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 el URI. Por ejemplo, para la URIhttp://example.com/customers, se puede esperar que las solicitudes POST representen a nuevos clientes, cada uno de los cuales incluye su nombre, dirección, detalles de contacto, etc. Los primeros diseñadores de sitios web se desviaron de este concepto original de dos maneras importantes. En primer lugar, no existe ninguna razón técnica para que un 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, es más probable que la última parte de un URI describa la página de procesamiento de la aplicación web y su tecnología, como http://example.com/applicationform.php. En segundo lugar, dada la limitación natural de la mayoría de los navegadores web para usar solo GET o POST, los diseñadores sintieron la necesidad de reutilizar POST para realizar muchas otras tareas de envío y administración de datos, incluida la alteración de los registros existentes y su eliminación.

Los esfuerzos de algunos escritores influyentes para remediar el primer punto comenzaron en 1998. Los marcos de aplicaciones web como Ruby on Rails y otros facilitan a los diseñadores proporcionar URL semánticas a sus usuarios. Con respecto al segundo punto, es posible usar secuencias de comandos del lado del cliente, o escribir aplicaciones independientes, para hacer uso de los otros métodos HTTP donde sean relevantes, pero fuera de esto, la mayoría de los formularios web que envían o modifican los datos del servidor continúan. para usar POST para el propósito.

Eso no quiere decir que cada formulario web deba especificar 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 tener method="get"especificado.

Hay momentos en que HTTP GET es menos adecuado incluso para la recuperación de datos. Un ejemplo de esto es cuando sería necesario 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 manejarán sin truncamiento o error. La codificación porcentual de caracteres reservados en URL y cadenas de consulta puede aumentar significativamente su longitud y, mientras que Apache HTTP Server puede manejar hasta 4000 caracteres en una URL, Microsoft Internet Explorer está limitado a 2048 caracteres en cualquier URL.Del mismo modo, HTTP GET no debe utilizarse cuando se deba enviar información confidencial, como nombres de usuario y contraseñas, junto con otros datos para completar la solicitud. Incluso si se usa HTTPS, lo que evita que los datos sean interceptados en tránsito, el historial del navegador y los registros del servidor web probablemente contendrán la URL completa en texto sin formato, que puede quedar expuesto si cualquiera de los sistemas es pirateado. En estos casos, se debe utilizar HTTP POST.

Uso para enviar formularios web

Cuando un navegador web envía una solicitud POST desde un elemento de formulario web, el tipo de medio de Internet predeterminado es "aplicación/x-www-form-urlencoded". Este es un formato para codificar pares clave-valor con claves posiblemente 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 al reemplazar los espacios con el carácter '+' y luego usar la codificación porcentual en todos los demás caracteres no alfanuméricos.

Por ejemplo, los pares clave-valor

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

se codifican como

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

A partir de HTML 4.0, los formularios también pueden enviar datos en varias partes/datos de formulario como se define en RFC 2388 (consulte también RFC 1867 para ver una versión experimental anterior definida como una extensión de HTML 2.0 y mencionada en HTML 3.2).

El caso especial de un POST a la misma página a la que pertenece el formulario se conoce como devolución de datos.

Afectando el estado del servidor

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 de 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 segundas o futuras". 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, hay razones por las que POST se usa incluso para solicitudes idempotentes, especialmente si la solicitud es muy larga. Debido a las restricciones en las direcciones URL, la cadena de consulta que genera el método GET puede volverse muy larga, especialmente debido a la codificación porcentual.