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 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 defina 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 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 una serie de métodos de solicitud o 'verbos', incluidos POST y GET, así como PUT, DELETE y muchos otros. Los navegadores web normalmente utilizan sólo GET y POST, pero las aplicaciones en línea RESTful utilizan 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 . [1] Por ejemplo, para el 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 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 cual 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 . 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 gestión de datos, incluida la alteración de 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] [ se necesita una mejor fuente ] 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 utilizar secuencias de comandos del lado del cliente , o escribir aplicaciones independientes, para hacer uso de otros métodos HTTP cuando sean relevantes, [3] pero fuera de esto, la mayoría de los formularios web que envían o modifican Los datos del servidor continúan utilizando POST para este propósito.
Eso no quiere decir que cada formulario web deba especificarlo method="post"en su etiqueta de apertura . Se utilizan muchos formularios 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 method="get"especificar. [4]
Hay ocasiones en las que HTTP GET es menos adecuado incluso para la recuperación de datos. Un ejemplo de esto es cuando es 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 ni error. La codificación porcentual de caracteres reservados en URL y cadenas de consulta puede aumentar significativamente su longitud, y mientras que el servidor HTTP Apache puede manejar hasta 4000 caracteres en una URL, [5] Microsoft Internet Explorer está limitado a 2048 caracteres en cualquier URL. [6] Del mismo modo, HTTP GET no debe usarse cuando se debe enviar información confidencial, como nombres de usuario y contraseñas, junto con otros datos para que se complete la solicitud. Incluso si se utiliza HTTPS , evitando 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 plano, que puede quedar expuesto si cualquiera 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 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 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: Gareth WylieEdad: 24Fórmula: a+b == 21
están codificados 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 multiparte/datos de formulario como se define en RFC 2388 (consulte también RFC 1867 para obtener 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 .
Según RFC 7231, el método POST no es idempotente , lo que significa que es posible que varias solicitudes idénticas no tengan 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". [10] [11] Por esta razón, los rastreadores web , como los indexadores de motores de búsqueda, normalmente utilizan los métodos GET y HEAD exclusivamente, para evitar que sus solicitudes automatizadas realicen tales acciones.
Sin embargo, existen razones por las que POST se utiliza 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, especialmente debido a la codificación porcentual . [10]
El método POST solicita que el recurso de destino procese la representación incluida en la solicitud de acuerdo con la semántica específica del recurso.