En programación, POST es uno de los muchos métodos de solicitud admitidos por el protocolo HTTP utilizado en la World Wide Web. El método de solicitud POST es para enviar una solicitud donde el servidor web acepta los datos incluidos en el cuerpo del mensaje para su almacenamiento. A menudo se utiliza para cargar un archivo o enviar un formulario web completo .
Por el contrario, el método HTTP GET está diseñado para recibir información del servidor. Como parte de una solicitud GET, se pueden pasar algunos datos en la cadena de consulta URI, indicando, por ejemplo, términos de búsqueda, intervalos de fechas u otra información que define la solicitud. 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. Los campos de encabezado en una solicitud POST suelen indicar el tipo de contenido .
La World Wide Web y el protocolo HTTP se basan en varios métodos de solicitud o "verbos", incluidos POST y GET, así como PUT, DELETE y muchos otros. Los navegadores web generalmente solo usan GET y POST, pero las aplicaciones REST en línea exigen muchos más. El método POST está destinado a enviar una representación de una nueva entidad al servidor para que se almacene como un subrecurso del recurso identificado por el URI. Por ejemplo, para el URI http://example.com/customers (enlace inalcanzable) , las solicitudes POST podrían representar nuevos clientes, cada uno con un nombre, dirección, información de contacto y similares. Los desarrolladores de sitios web se han alejado de este concepto por dos razones. Primero, no hay ninguna razón técnica para que un URI describa textualmente los recursos web subyacentes donde se almacenarán los datos enviados por el método POST. De hecho, es más probable que la última parte del URI describa la página de procesamiento de la aplicación web y su tecnología, como http://example.com/applicationform.php (enlace inactivo) . En segundo lugar, dada la limitación natural de la mayoría de los navegadores web para usar solo los métodos GET o POST, los desarrolladores reconocieron la necesidad de agregar más funciones al método POST, incluida la modificación de las entradas existentes y su eliminación.
Los intentos de corregir la primera deficiencia comenzaron en 1998. Los marcos de aplicaciones web , como Ruby on Rails y otros, han ayudado a los desarrolladores a proporcionar direcciones URL legibles por humanos a sus usuarios . En cuanto al segundo punto, puede escribir scripts del lado del cliente o aplicaciones independientes que usarán otros métodos HTTP y luego convertirlos a un método POST.
Es decir, no se puede decir que todo formulario web deba contener un método POST en la etiqueta de apertura. Muchos formularios se utilizan con mayor precisión para recuperar información del servidor, sin cambiar las bases de datos subyacentes. Para tales formularios de búsqueda, el método GET es ideal.
Hay momentos en que HTTP GET es menos adecuado incluso para obtener datos. Un ejemplo es cuando se necesita escribir una gran cantidad de datos en la URL. Los navegadores y los servidores web pueden tener límites en la longitud de las URL que procesan sin truncamiento o error. Los caracteres reservados de codificación URL en la dirección y la cadena de consulta pueden aumentar considerablemente la longitud, mientras que el servidor Apache HTTP puede manejar hasta 4000 caracteres (8190 bytes) en una URL [1] , Microsoft Internet Explorer limita la longitud de cualquier URL a 2048 caracteres .
Asimismo, HTTP GET no debe utilizarse para información confidencial, como nombres de usuario y contraseñas, que deben proporcionarse junto con otros datos para completar la solicitud. Incluso con HTTPS , que evita las escuchas en tránsito, es probable que los historiales del navegador y los registros del servidor web contengan URL completas en texto sin formato que se pueden encontrar si el sistema es pirateado. En estos casos, se utiliza HTTP POST.
Cuando un navegador web envía una solicitud POST con elementos de formulario web, el tipo de datos de medios de Internet predeterminado es application/x-www-form-urlencoded. Este es un formato para codificar pares clave-valor con la posibilidad de claves duplicadas. Cada par clave-valor está separado por &, la clave está separada del valor por =. En claves y valores, los espacios se reemplazan con +, y luego, mediante la codificación de URL, se reemplazan todos los caracteres no alfanuméricos.
Por ejemplo,
Nombre: Jonathan Doe Edad: 23 Fórmula: a + b == 13%!será codificado como
Nombre=Jonathan+Doe&Edad=23&Fórmula=a+%2B+b+%3D%3D+13+%25%21Desde HTML 4.0, los formularios también pueden enviar datos en varias partes/formularios como se define en RFC 2388 (ver también RFC 1867 para una versión experimental anterior definida como una extensión de HTML 2.0 y referenciada en HTML 3.2). Un caso especial del método POST cuando se accede a la misma página que posee el formulario se denomina devolución de datos.
En RFC 2616 , el método POST debe usarse para cualquier contexto en el que la solicitud no sea idempotente : es decir, provoca un cambio de estado del servidor cada vez que se ejecuta, como publicar un comentario en una publicación de blog o una votación en Internet. En la práctica, el método GET a menudo se reserva, no solo para acciones idempotentes, sino también para acciones nulopotentes, es decir, sin efectos secundarios (a diferencia de "sin efectos secundarios en la segunda y posteriores solicitudes" como con las operaciones idempotentes). Por esta razón, los sitios de motores de búsqueda, como los indexadores de motores de búsqueda, suelen utilizar el método GET exclusivamente para evitar que las solicitudes automatizadas realicen alguna acción.
Sin embargo, hay razones por las que POST se usa incluso para solicitudes idempotentes, especialmente si la solicitud usa caracteres que no son ASCII o es muy larga, debido a restricciones de URL: la cadena de consulta del método GET puede ser muy larga, especialmente cuando se usa la codificación de URL.