GET vs POST

HTTP ENVIAR las solicitudes suministran datos adicionales del cliente (navegador) al servidor en el cuerpo del mensaje. A diferencia de, OBTENER las solicitudes incluyen todos los datos requeridos en la URL. Los formularios en HTML pueden usar cualquiera de los dos métodos especificando method = "POST" o method = "GET" (predeterminado) en el elemento. El método especificado determina cómo se envían los datos del formulario al servidor. Cuando el método es GET, todos los datos del formulario se codifican en la URL, anexados a la acción URL como parámetros de cadena de consulta. Con POST, los datos del formulario aparecen dentro del cuerpo del mensaje de la solicitud HTTP.

Gráfica comparativa

Cuadro comparativo GET versus POST

OBTENER	ENVIAR

Historia	Los parámetros permanecen en el historial del navegador porque son parte de la URL	Los parámetros no se guardan en el historial del navegador.
Marcado	Se puede marcar como favorito.	No se puede marcar como favorito.
Botón ATRÁS / comportamiento de reenvío	Las solicitudes GET se vuelven a ejecutar pero no se pueden volver a enviar al servidor si el HTML se almacena en el caché del navegador.	El navegador generalmente alerta al usuario de que los datos deberán volver a enviarse.
Tipo de codificación (atributo enctype)	aplicación / x-www-form-urlencoded	multipart / form-data o application / x-www-form-urlencoded Use codificación multipart para datos binarios.
Parámetros	se puede enviar, pero los datos de los parámetros se limitan a lo que podemos incluir en la línea de solicitud (URL). Es más seguro usar menos de 2K de parámetros, algunos servidores manejan hasta 64K	Puede enviar parámetros, incluyendo la carga de archivos, al servidor.
Hackeado	Más fácil de hackear para los niños script	Más difícil de hackear
Restricciones en el tipo de datos del formulario	Sí, solo se permiten caracteres ASCII.	Sin restricciones. También se permiten datos binarios..
Seguridad	GET es menos seguro en comparación con POST porque los datos enviados son parte de la URL. Así que se guarda en el historial del navegador y los registros del servidor en texto plano.	POST es un poco más seguro que GET porque los parámetros no se almacenan en el historial del navegador o en los registros del servidor web.
Restricciones en la longitud de los datos del formulario	Sí, ya que los datos del formulario están en la URL y la longitud de la URL está restringida. Un límite de longitud de URL seguro suele ser de 2048 caracteres pero varía según el navegador y el servidor web.	Sin restricciones
Usabilidad	El método GET no debe utilizarse al enviar contraseñas u otra información confidencial.	Método POST utilizado al enviar contraseñas u otra información confidencial.
Visibilidad	El método GET es visible para todos (se mostrará en la barra de direcciones del navegador) y tiene límites en la cantidad de información para enviar.	Las variables del método POST no se muestran en la URL.
En caché	Se puede almacenar en caché	No en caché

Contenidos: GET vs POST

1 diferencias en la forma de presentación
- 1.1 Pros y contras
2 diferencias en el procesamiento del lado del servidor
3 Uso recomendado
4 ¿Qué pasa con HTTPS?
5 referencias

Diferencias en la forma de presentación

La diferencia fundamental entre MÉTODO = "GET" y MÉTODO = "POST" es que corresponden a diferentes solicitudes HTTP, como se define en las especificaciones HTTP. El proceso de envío para ambos métodos comienza de la misma manera: un conjunto de datos de formulario es construido por el navegador y luego codificado de la manera especificada por el enctype atributo. por METHOD = "POST la enctype atributo puede ser multipart / form-data o aplicación / x-www-form-urlencoded, mientras que para MÉTODO = "GET", solamente aplicación / x-www-form-urlencoded esta permitido. Este conjunto de datos de formulario se transmite al servidor..

Para el envío de formularios con METHOD = "GET", el navegador construye una URL tomando el valor de acción atributo, añadiendo un ? para ello, luego anexando el conjunto de datos del formulario (codificado utilizando el tipo de contenido application / x-www-form-urlencoded). El navegador luego procesa esta URL como si estuviera siguiendo un enlace (o como si el usuario hubiera escrito la URL directamente). El navegador divide la URL en partes y reconoce un host, luego envía a ese host una solicitud GET con el resto de la URL como argumento. El servidor lo lleva desde allí. Tenga en cuenta que este proceso significa que los datos del formulario están restringidos a los códigos ASCII. Se debe tener especial cuidado en codificar y decodificar otros tipos de caracteres al pasarlos a través de la URL en formato ASCII.

El envío de un formulario con METHOD = "POST" hace que se envíe una solicitud POST, utilizando el valor de acción atributo y un mensaje creado de acuerdo con el tipo de contenido especificado por el enctype atributo.

Pros y contras

Dado que los datos del formulario se envían como parte de la URL cuando OBTENER es usado --

Los datos del formulario están restringidos a los códigos ASCII. Se debe tener especial cuidado en codificar y decodificar otros tipos de caracteres al pasarlos a través de la URL en formato ASCII. Por otro lado, los datos binarios, las imágenes y otros archivos se pueden enviar a través de MÉTODO = "POST"
Todos los datos del formulario rellenados son visibles en la URL. Además, también se almacena en el historial de navegación web del usuario / registros para el navegador. Estas cuestiones hacen OBTENER menos seguro.
Sin embargo, una ventaja de los datos de formulario que se envían como parte de la URL es que se pueden marcar las URL y usarlas directamente y omitir completamente el proceso de llenado de formularios..
Existe una limitación sobre la cantidad de datos de formulario que se pueden enviar porque las longitudes de las URL son limitadas.
Script Kiddies puede exponer más fácilmente las vulnerabilidades en el sistema para hackearlo. Por ejemplo, Citibank fue hackeado cambiando los números de cuenta en la cadena de URL.^[1] Por supuesto, los hackers experimentados o los desarrolladores web pueden exponer dichas vulnerabilidades incluso si se usa POST; Es un poco más difícil. En general, el servidor debe sospechar de cualquier dato enviado por el cliente y protegerse contra Referencias Inseguras de Objetos Directos.

Diferencias en el procesamiento del lado del servidor

En principio, el procesamiento de los datos de un formulario enviado depende de si se envía con MÉTODO = "GET" o MÉTODO = "POST". Dado que los datos se codifican de diferentes maneras, se necesitan diferentes mecanismos de decodificación. Por lo tanto, en general, cambiar el MÉTODO puede requerir un cambio en el script que procesa el envío. Por ejemplo, cuando se utiliza la interfaz CGI, el script recibe los datos en una variable de entorno (QUERYSTRING) cuando OBTENER se utiliza Pero cuando ENVIAR se utiliza, los datos del formulario se pasan en el flujo de entrada estándar (stdin) y el número de bytes a leer viene dado por el encabezado Content-length.

Uso recomendado

Se recomienda GET al enviar formularios "idempotentes", aquellos que no "alteran significativamente el estado del mundo". En otras palabras, formularios que involucran consultas de base de datos solamente. Otra perspectiva es que varias consultas idempotentes tendrán el mismo efecto que una sola consulta. Si hay actualizaciones de la base de datos u otras acciones, como la activación de correos electrónicos, se recomienda el uso de POST.

Desde el blog del desarrollador de Dropbox:

un navegador no sabe exactamente lo que hace un formulario HTML en particular, pero si el formulario se envía a través de HTTP GET, el navegador sabe que es seguro volver a intentar el envío automáticamente si hay un error de red. Para los formularios que utilizan HTTP POST, puede que no sea seguro volver a intentarlo, por lo que el navegador solicita primero al usuario la confirmación..

Una solicitud "GET" a menudo se puede almacenar en caché, mientras que una solicitud "POST" difícilmente puede ser. Para los sistemas de consulta, esto puede tener un impacto considerable en la eficiencia, especialmente si las cadenas de consulta son simples, ya que los cachés pueden servir para las consultas más frecuentes.

En ciertos casos, utilizando ENVIAR Se recomienda incluso para consultas idempotentes:

Si los datos del formulario contendrían caracteres no ASCII (como los caracteres acentuados), entonces MÉTODO = "GET" no es aplicable en principio, aunque puede funcionar en la práctica (principalmente para los caracteres ISO Latin 1).
Si el conjunto de datos del formulario es grande - digamos, cientos de personajes - entonces MÉTODO = "GET" puede causar problemas prácticos con implementaciones que no pueden manejar esas URL largas.
Es posible que desee evitar MÉTODO = "GET" para que los usuarios no puedan ver cómo funciona el formulario, especialmente para que los campos "ocultos" (TIPO DE ENTRADA = "OCULTADO") estén más ocultos al no aparecer en la URL. Pero incluso si usas campos ocultos con MÉTODO = "POST", Seguirán apareciendo en el código fuente HTML..

¿Qué pasa con HTTPS??

Actualizado el 15 de mayo de 2015: Específicamente cuando se usa HTTPS (HTTP sobre TLS / SSL), POST ofrece más seguridad que GET?

Esta es una pregunta interesante. Digamos que haces una solicitud GET a una página web:

 OBTENGA https://www.example.com/login.php?user=mickey&passwd=mini

Suponiendo que su conexión a Internet está siendo monitoreada, ¿qué información sobre esta solicitud estará disponible para el snooper? Si se usa POST en su lugar, y los datos de usuario y contraseña se incluyen en las variables POST, ¿será más seguro en el caso de las conexiones HTTPS??

La respuesta es no. Si realiza una solicitud GET de este tipo, el atacante solo sabrá la siguiente información que supervisa su tráfico web:

El hecho de que hiciste una conexión HTTPS
El nombre de host - www.example.com
La longitud total de la solicitud.
La duración de la respuesta.

La parte de la ruta de la URL, es decir, la página real solicitada, así como los parámetros de la cadena de consulta, están protegidas (encriptadas) mientras están "sobre el cable", es decir, en tránsito hacia el servidor de destino. La situación es exactamente la misma para las solicitudes POST..

Por supuesto, los servidores web tienden a registrar la URL completa en texto sin formato en sus registros de acceso; por lo tanto, enviar información confidencial a través de GET no es una buena idea. Esto se aplica independientemente de si se utiliza HTTP o HTTPS.

Referencias

wikipedia: POST (HTTP)
Métodos de solicitud HTTP
HTTP Post - W3.org
Obtener HTTP - W3.org
¿HTTPS oculta las URL a las que se accede?? - Intercambio de pila

Tecnología