En programación HTTP, peticiones tipo POST suplen data adicional del cliente (el buscador, o "browser") al servidor en el cuerpo del mensaje. Como contraste, las peticiones tipo GET incluyen toda la data requerida en el enlace (el URL, siglas en inglés). Formularios en HTML pueden usar cualquier método, usando method="POST" o method="GET" (default) en el elemento <form>. El método especificado determina cómo es que la data del formulario será enviada al servidos. Cuando el método es GET, toda la data del formulario se codifica dentro del URL, apegado al URL de acción, como parámetros de la petición directa (query string). Con POST, la data del formulario aparece dentro del cuerpo del mensaje de petición de HTTP.

Tabla de comparación

GET versus POST Tabla de comparación
Edit this Tabla de comparaciónGETPOST
  • current rating is 4.12/5
  • 1
  • 2
  • 3
  • 4
  • 5
(1253 ratings)
  • current rating is 4.43/5
  • 1
  • 2
  • 3
  • 4
  • 5
(1376 ratings)
Historial Los parámetros se guardan en el historial del buscador (browser) porque son parte del enlace (URL) No se guardan los parámetros en el historial del buscador
Archivación (bookmark) Puede ser archivado No puede ser archivado
Resultado al usar BACK/resometer petición Las peticiones GET se ejecutan de nuevo pero no se pueden re-someter al servidor si el HTML está guardado en el almacenaje (cache) del "browser" El "browser" usualmente le avisa al usuario que la data tiene que ser re-sometida
Tipo de codificación (atributos enctype) application/x-www-form-urlencoded multipart/form-data o application/x-www-form-urlencoded
Parámetros Puede enviarlos pero la data de parámetros está limitado a lo que cabe en el URL. Es más seguro usar menos de 2K de los parámetros (algunos servidores llegan a 64K) Puede enviar parámetros, incluyendo subir archivos al servidor
Vulnerabilidad Más fácil de atacar Más difícil de atacar
Restricciones en el tipo de data en el formulario Sí, sólo se permiten caracteres ASCII No tiene restricciones. Se permite data binaria.
Restricciones en la cantidad de data en formularios Sí porque la data del formulario está en el URL y hay un límite para URLS de 2,048 caracteres, aunque puede variar No tiene restricciones
Usabilidad El método GET no se debe usar para enviar claves de entrada o cualquier información sensitiva POST se debe usar para enviar claves de entrada o cualquier información sensitiva
Visibilidad GET está visible para todo el mundo (en la barra de URLS del buscador) y tiene límites a la cantidad de data que puede enviar La variables en POST no se ven en los URLs
Almacenable Se puede almacenar No se puede almacenar
Valores de variables grandes Límite de 7,607 caracteres Límite de 8 MB

Diferencias en someter formularios

la diferencia fundamental entre METHOD="GET" y METHOD="POST" es que corresponden a diferentes peticiones de HTTP, según se define en las especificaciones de HTTP. El proceso de someter data para ambos métodos comienza de la misma manera - el buscador (browser) construye un set de data del formulario y la codifica según los atributos dados. Para METHOD= "POST" el atributo enctype puede ser multipart/form-data o application/x-www-form-urlencoded, mientras que en METHOD="GET", sólo se permite application/x-www-form-urlencoded. El set de data del formulario se transmite al servidor.

Para someter el set de data del formulario bajo METHOD="GET", el "browser" construye el enlace (URL) tomando el valor del atributo action, le añade un ? a eso, entonces apega el set de data del formulario (codificado usando el tipo de contenido bajo application/x-www-form-urlencoded.) El "browser" entonces procesa el enlace como argumento (argument). El servidor lo toma de ahí en adelante. Nota que este proceso significa que la data del formulario está restringida a códigos ASCII. Hay que tener cuidado para codificar y decodificar ambos tipos de caracteres cuando se pasan a un enlace (URL) en formato ASCII.

Someter un formulario (form) usando METHOD="POST" causa que se envíe una petición POST usando el valor del atributo action creado de acuerdo al tipo de contenido especificado por el atributo enctype.

Pros y contras

Como la data del formulario se envía como parte del enlace cuando se usa GET:

Diferencias en procesamiento en servidores

En principio, el procesamiento de la data de formulario depende de si fue enviado por METHOD="GET" o METHOD="POST". Como la data se codifica de maneras diferentes, se necesitan diferentes mecanismos de decodificación. Por lo tanto, cambiar el METHOD puede necesitar un cambio en la programación que procesa la data. Por ejemplo, en una interfaz de imágenes gráficas de computadora (CGI, en inglés), se recibe la data en una variable ambiental (environment variable QUERYSTRING) cuando se usa GET. Pero cuando se usa POST, la data se pasa en un flujo estándar de entrada (stdin) y el número de bits a leerse lo da el encabezado (header) del contenido (Content-length).

Usos recomendados

GET se recomienda para someter formularios tipo "idempotent," o sea, aquellos que "no alteran el mundo de forma significativa." Eso usualmente se refiere a peticiones de bases de datos solamente. Otra perspectiva es que varias peticiones tipo idempotent pueden tener el mismo efecto de una sola petición. Si la base de datos requiere ponerse al día a menudo o hay otras acciones a tomarse (enviar emails, por ejemplo), se recomienda usar POST.

Del blog de desarrollo de Dropbox:

Un buscador no sabe lo que un formulario de HTML hace, pero si el formulario se somete via HTTP GET. el buscador sabe que es seguro tratar de nuevo a buscar la información si hay un error en la red. Para formularios que usan HTTP POST, puede que no sea seguro tratar de nuevo, así que el buscador le pregunta primero al usuario para una confirmación.

Una petición "GET" es almacenable (cacheable), mientras que las peticiones "POST" apenas lo son. Para sistemas de peticiones esto puede tener un impacto significativo en eficiencia, especialmente si las peticiones son simples, ya que se pueden almacenar las más frecuentes.

En ciertos casos, es mejor usar POST aún para peticiones tipo idempotent:

Referencias


Comparte esta comparación via:

Si usted lee este momento, usted debe seguirnos:

"GET vs POST." Diffen.com. Diffen LLC, n.d. Web. 17 Mar 2024. < >