Cualquiera puede formular una pregunta

Stack Overflow en español es un sitio de

preguntas y respuestas para programadores
y profesionales de la informática. Solo te Cualquiera puede responder
toma un minuto registrarte.

Regístrate para unirte a esta comunidad Se vota a favor de las mejores

respuestas, y éstas suben a los
primeros puestos

¿Cuando debo usar los métodos POST y GET?

Formulada hace 3 años y 3 meses Activa hace 3 años y 2 meses Vista 50k veces

¿Cuales son las diferencias entre los métodos GET y POST ?

• ¿Es la única diferencia que se pueden ver las variables en el método GET en la URL
26 y en el POST esta escondido?

¿Que (des)ventajas tiene uno al otro?

• ¿Se puede decir que las variables enviado vía POST están seguros?
7

php http-post http-get

editada el 26 nov. 16 a las 18:10 formulada el 20 nov. 16 a las 18:16

Black Sheep
11.8k 5 28 59

Yo sé que POST es más seguro y debe usarse cuando vallamos a hacer modificaciones en el
servidor, como delete, update, alter. Pero estoy esperando a que alguien dé una respuesta
bien elaborada, pues personalmente y en lo poco que llevo en la programación, aún no le
encuentro sentido a usar el método GET, mi pregunta interna sería, ¿Por qué usar GET, si post
permite hacer lo mismo (o eso creo) y es más seguro? – Roberto Sepúlveda Bravo el 20 nov.
16 a las 18:28

2 @RobertoSepúlvedaBravo ¿Cómo es POST más seguro que GET? Que en el GET los
parámetros sean "visibles" no implica que los valores "invisibles" del POST sean/estén más
seguros. – Alvaro Montoro ♦ el 20 nov. 16 a las 22:23

Al usar este sitio,@AlvaroMontoro Podrías

reconoces haber leido ydar alguna referencia
entendido de esade
nuestra Política vulnerabilidad que podría
Cookies, Política de presentar
POST? A mí me parece en
Privacidad, y nuestros Términos de Servicio. cierto grado más seguro que GET porque cualquier persona sin
 muchos conocimientos de programación podría enviar quizás qué cosa por el navegador. Eso
no pasaría si uso POST, pero alguien que sí tenga conocimientos quizá pueda vulnerar POST
y hacer el mismo daño que alguien podría hacer por GET. Por eso me urge saber si puedo
tapar tal vulnerabilidad. – Roberto Sepúlveda Bravo el 20 nov. 16 a las 22:46

3 Los datos del POST no son invisibles en HTTP. Vale que una persona no los vea, pero pueden
ser leídos por un programa de manera tan sencilla como los datos pasados por GET. Para que
fuesen más seguros deberías usar una conexión segura (HTTPS/SSL) – Alvaro Montoro ♦ el
20 nov. 16 a las 22:50

7 respuestas

Métodos GET VS POST

Muchas veces pensábamos erróneamente sobre la utilización de GET y POST . Tenemos

28 a entender que cuando doy clic en una URL eso es GET y cuando envío un formulario es
POST . Solemos pensar que enviando las peticiones por método POST los datos viajan
seguros, por no ir como parte de la URL como lo hace GET . Este concepto es erróneo,
estas no son las diferencias entre links y formularios.

Tanto el método GET como POST son protocolo HTPP el cual envía al servidor como
petición (request) y recibe una respuesta a dicha solicitud (response). A mi criterio, aquí
está la parte de la confusión sobre los objetivos reales de ambos métodos.

Redefinamos los conceptos

El concepto GET es obtener información del servidor. Traer datos que están
almacenadas en el servidor, ya sea una base de datos o archivo al cliente.
Independientemente de que para eso tengamos que enviar (request) algún dato que será
procesado para luego devolver la respuesta (response) que esperarnos, un ejemplo sería
Al usar este sitio,un
recibir reconoces haber para
identificador leido yobtener
entendido
un nuestra
artículoPolítica de Cookies
de la base , Política de
de datos.
Privacidad, y nuestros Términos de Servicio.
 El concepto POST en cambio es enviar información desde el cliente paraa que sea
procesada y actualice o agregue información en el servidor, como sería la carga o
actualización en si de un artículo. Cuando enviamos (request) datos a través de un
formulario, estos son procesados y luego a través de una redirección, ejemplo
devolvemos (response) alguna página con información.

Tanto GET como POST solicitan una respuesta del servidor y ahí donde parecen que los
conceptos son iguales ya que con ambos se podría lograr los mismos objetivos. Yo
podría, aunque no es correcto, enviar por GET ciertos datos en una URL u actualizar o
insertar dicha información en mi base de datos, pero realmente eso le corresponde al
método POST . De la misma manera podría solicitar una página diferente por medio de
POST y simplemente mostrarla como respuesta, aunque eso debería ser a través de una
llamada GET .

Las llamadas por método GET pueden ser cacheadas (historial navegador), indexadas
por buscadores, agregar los enlaces a nuestros favoritos o hasta pasar una URL
completa a otra persona para que ingresa a dicha página. Con el método POST sin
embargo no se puede hacer esto.

Generalmente usamos links para ejecutar llamadas GET ya que la idea del link es
simplemente “solicitar” una información (pagina) al servidor y que sea devuelta como
una respuesta. Mientras usamos formularios para actualizar datos, como artículos,
usuarios, etc. también en cuenta que por el método POST también se puede enviar más
cantidad de datos que por GET .

Un caso de análisis.

Supongamos que tengamos un carrito de compras, con una URL que agregue productos
al carrito de compras. Generalmente si hacemos esa URL quedaría algo así
(misitio.com/agregar_item.php?id=1). Al ser una llamada GET , Google podría indexar esa
URL y podría aparecer en el buscador la palabra carrito. El problema aquí, si el visitante
ejecutaría esa página automáticamente agregaría ese ítem al carrito de compras, con lo
cual no es la idea ya que el visitante al buscar el carrito de compras debería simplemente
entrar al sitio y no agregar ningún ítem que ni siquiera sabe cuál es. Por lo tanto, vemos
que para este caso por más que usamos una URL , deberíamos usar una llamada al
método POST , por ejemplo, como lo usa el framework Symfony , ejemplo:

<a onclick="f = document.createElement('form'); document.body.appendChild(f);

f.method = 'POST'; f.action = this.href; f.submit();return false;"
href="agregar_item.php?id=1">Añadir al carrito
</a>

Lo que hace este URL es muy sencillo, por medio del evento onclick de JavaScript ,
crea dinámicamente un formulario, le dice que será POST (ya que por defecto sería GET ),
le asigna la URL del enlace al action del form, envía el formulario y retorna false para no
Al usar este sitio, reconoces
ejecutar el link enhaber leidohacer
sí. Para y entendido nuestra
esto con Política
Symfony de Cookies, Política
simplemente usamosdeel helper link_to
Privacidad , y nuestrosla
agregando Términos
opción de Servicio. :
post=true
 <?php echo link_to('Añadir al carrito', 'agregar_item.php?id=1', 'post=true') ?>

Fuente donde lei el articulo: http://blog.micayael.com/2011/02/09/metodos-get-vs-post-

del-http/

editada el 20 nov. 16 a las 20:41 respondida el 20 nov. 16 a las 20:34

D.Bulten
5,105 2 17 37

Existirán casos de utilidad o de fuerza en los cuales para nuestras aplicaciones web debamos
usar GET en lugar de POST? Leo y re-leo y no le veo la razón de existir al método GET. –
Roberto Sepúlveda Bravo el 20 nov. 16 a las 22:21

1 @RobertoSepúlvedaBravo Los valores del GET se podrían guardar en la caché y podría ser
más rápido por ello. – Alvaro Montoro ♦ el 20 nov. 16 a las 22:26

 

Quiero visualizar/explicar en forma más practico la diferencia entre los métodos POST 's y
GET 's.

15 Para eso vamos a usar un <form> y para los ejemplos usamos estos valores:

"user" = "pepe" | "pass" = "cocoloco"

Formulario con el método GET :

<form action="login.php" method="get">

<input type="text" name="user">
<input type="password" name="pass">
<input type="submit" name="submit">
</form>

Si no incluimos el atributo method por defecto se envia medio GET .

Con el elemento HTML Anchor <a> se puede enviar también (y solamente) por medio
GET :

<a href="/libros.php?autor=pepe&libro=cocoloco">Un libro interesante</a>

Formulario con el método POST :

<form action="login.php" method="post">

<input type="text" name="user">
<input type="password" name="pass">
<input type="submit" name="submit">
Al usar este sitio, reconoces haber leido y entendido nuestra Política de Cookies, Política de
</form>
Privacidad, y nuestros Términos de Servicio.
 Veamos como trata cada uno las solicitudes:

Encabezado de solicitud / Request header method="get" :

• GET /login.php?user=pepe&pass=cocoloco&submit=Enviar HTTP/1.1

• Host: example.com

Vista de la URL : example.com/login.php?user=pepe&pass=cocoloco&submit=Enviar

Encabezado de solicitud / Request header del method="post" :

• POST /login.php HTTP/1.1

• Host: example.com
• Content-Length: 37
• Content-Type: application/x-www-form-urlencoded

Vista de la URL : example.com/login.php

Por que no vemos en el method="post" los parámetros/valores?

Para eso hay que saber que el HTTP Request (solicitud HTTP) esta formado por varios
componentes, nos vamos a fijar solo cuales nos interesa ahora mismo:

• URI (Dirección)
• Request Header (Cabecera)
• Response Body (Cuerpo)

La diferencia en el GET y POST es que el GET no tiene el componente Response Body

(Cuerpo), por eso mismo incluye el GET los parámetros/valores en la URI (Dirección) y
por lo tanto visible para todos.

En el caso del POST , sabemos ahora, que lleva el contenido del mensaje en el Response
Body (Cuerpo).

Si nos vamos a la consola del navegador (en mi caso Chrome)

Network => Name: login.php => Headers => Form Data

podemos ver el contenido del cuerpo:

user=pepe&pass=cocoloco&submit=Enviar

El Content-Length: 37 nos indica la longitud del contenido.

El Content-Type nos indica los tipos de datos que se envía.

Al usar este sitio, reconoces haber leido y entendido nuestra Política de Cookies, Política de
Si, yquieres
Privacidad nuestrossaber másde
Términos deServicio
los distintos
. tipos de datos => MIME
 Ahora dirán algunos:

Que bien! Si uso el método POST no puede ver nadie la super contraseña o datos
sensibles....

Ehm... pues lamentablemente NO! (si lo mandas por http ).

Problema:

Ataque del hombre en el medio...(traducido literalmente del inglés: Man-In-the-Middle

Attack) es un ataque de Intermediario.

Wikipedia: Ataque de Intermediario

Un ataque en el que se adquiere la capacidad de leer, insertar y modificar a voluntad,

los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre
ellos ha sido violado.

Solución:

Si quieres enviar tu mega super dato secreto a tu servidor tienes que usar:

https - Protocolo seguro de transferencia de hipertexto

Ahora dirán:

Si esta cifrado puedo usar el método GET para enviar los datos sensibles!

Mmmmm pues... nop!

Cierto es que todo esta encriptado, pero en el caso del método GET las consultas se
quedan guardados en los logs del servidor y entonces si sería accesible de una u otra
manera.

Conclusión corta:

Usa siempre POST para datos sensibles y SSL HTTPS ... si quieres estar seguro y · !

Comparaciones:

| GET | POST |
-----------------------------------------------------------------------
Historial | Los parámetros permanecen | Los parámetros no se |
| en el historial del | guardan en el historial |
| navegador porque forman | del navegador |
| parte de la URL | |
Al usar este sitio, reconoces haber leido y entendido nuestra Política de Cookies, Política de
-----------------------------------------------------------------------
Privacidad,Guardar
y nuestrosen Términos
| Es de
posible
Servicio. | No es posible |
 Favoritos | | |
-----------------------------------------------------------------------
Cached | Es posible | No es posible |
-----------------------------------------------------------------------
Visibilidad | Es visible para todos - | No se muestra en la URL |
| se mostrará en la barra | |
| de direcciones del | |
| navegador | |
-----------------------------------------------------------------------
Usabilidad | No se debe utilizar para | Utilizado para enviar |
| enviar contraseñas u otra | contraseñas u otra |
| información sensible | información sensible |
-----------------------------------------------------------------------
Comportamiento | Las solicitudes se | El navegador suele |
botón atrás / | vuelven a ejecutar pero | alertar al usuario de |
reenviar | no se puede volver a | que los datos tendrán |
| enviar al servidor, si el | que volver a enviarse |
| HTML se almacena en el | |
| cache del navegador | |
------------------------------------------------------------------------
Restricciones | El límite de longitud de | Sin restricciones |
en la longitud | la URL suele ser de 2048 | |
| caracteres, pero varía | |
| según el navegador y el | |
| servidor web | |
-----------------------------------------------------------------------
Seguridad | Es menos seguro porque | Es más seguro ya que no |
| los datos enviados forman | se guarda en el |
| parte de la URL, por lo | historial ni en los logs |
| tanto, se guarda en el | del servidor |
| historial del navegador y | |
| en los logs del servidor | |
-----------------------------------------------------------------------
Hacked | Más fácil de hackear | Difícil de hackear |
-----------------------------------------------------------------------

respondida el 21 nov. 16 a las 1:20

Black Sheep
11.8k 5 28 59

 

aparte de las que comentas, y cada una tiene su propia semántica de uso. En la vida
real, cada uno los maneja mas o menos a su antojo.
6 • GET -> Obtiene un recurso del nevagador. La dirección del recurso va en la petición
(de ahí los parámetros visibles). El contenido pasa por la caché del navegador.
• POST -> Envía unos datos al servidor. El servidor sabrá que hacer con ellos y los
procesará como sea pertinente (de ahí los parámetros invisibles. NO son
parámetros, son datos a almacenar en un recurso). Debería emplearse para la
creación de recursos nuevos, a los cuales el servidor les asignará una dirección. No
pasan
Al usar este sitio, por la haber
reconoces cachéleido
del ycliente.
entendido nuestra Política de Cookies, Política de
Privacidad, y nuestros Términos de Servicio.
 • PUT -> Envia un recurso a una posición exacta en el servidor. Es una especie de
GET inverso. Parámetros visibles (como en el GET).

respondida el 20 nov. 16 a las 18:28

Trauma
20.6k 3 28 56

Como información adicional a las otras respuestas, una diferencia importante entre GET
y POST es la cantidad de datos que se pueden enviar como parámetros. Al utilizar GET
6 existe un límite en la longitud de la URL (2000 caractéres) lo que se traduce en un límite
en la cantidad/longitud de los parámetros pasados. Esta limitación no existe en el caso
de POST ya que los parámetros no forman parte de la URL y por lo tanto pueden
enviarse (teoricamente) una cantidad de parámetros infinitamente grande.

respondida el 20 nov. 16 a las 20:33

VorteXavier
221 1 1

+1 por ser el único que menciona la limitación en el tamaño, que es una de las grandes
diferencias entre los dos. – Alvaro Montoro ♦ el 20 nov. 16 a las 22:05

1 Esa información es falsa. No existe en ninguna parte del protocolo HTTP definido por RFC un
límite a la longitud del URI asociado a una petición GET. Esa limitación de aproximadamente
2000 caracteres fue impuesta por IE, y actualmente es absolutamente dependiente del
navegador o del servidor web que puede arrojar una respuesta 413. – dwarandae el 20 dic. 16
a las 5:12

@dwarandae tiene razón. Ese límite es un límite de facto más que una limitación en la
implementación del protocolo. No obstante, no se me ocurre un caso en que sea "razonable"
usar una url de ese tamaño. – Muriano el 3 abr. 17 a las 12:43

Las respuestas que hay son generalmente correctas, pero no es la definición que más
me gusta, así que a pesar de que ya hay cuatro respuestas aquí va:
6 La diferencia básica es la idempotencia de GET; esto significa que el GET no tiene un
efecto en los datos relacionados1. Por ejemplo, si hago una operación para obtener las
películas de los cines de mi ciudad, o el resumen de una película, esta petición será
mediante GET (por más peticiones que haga, eso no afectará a qué películas se están
exhibiendo).

Esto permite al cliente tratar las peticiones GET con más libertad: puede cachearlas (o
no) si lo desea, en caso de repetir la petición (al hacer back en el navegador, por
ejemplo) no necesita advertir al usuario, etc.
Al usar este sitio, reconoces haber leido y entendido nuestra Política de Cookies, Política de
Privacidad, y nuestros Términos de Servicio.
 Por el contrario, POST implica que la petición puede cambiar datos en el servidor (por
ejemplo, que se reserve una entrada a mi nombre en un cine). Eso hace que haya que
ser más cuidadoso con las peticiones POST, ya que hay que evitar crear peticiones si no
se está seguro que es lo que el usuario quiere (el famoso mensaje de aviso al hacer
back con el navegador).

Una forma de minimizar los problemas del POST es POST-Redirect-GET; al enviar un

formulario POST no te devuelve los datos de la operación sino que te redirige a otra
página; desde esa página, con un GET de un id de transacción puedes ver los
resultados, por ejemplo el número de tu entrada de cine (así, puedes hacer back hasta
el GET para recuperar los resultados sin hacer el POST de nuevo).

Por supuesto, esto es a nivel de estándar, a nivel de implementación puedes hacer un

servicio GET que haga cambios en los datos del servidor, pero si luego tienes problemas
cuando los usuarios lo usan será tu responsabilidad por haber roto el protocolo.

1A veces es algo más complicado, por ejemplo las búsquedas en Google son GET y en
principio el hacer búsquedas no altera el resultado obtenido, pero también almacena las
búsquedas para hacer estadísticas y hacer cambios en sugestiones, publicidad, etc.

Se seguiría considerando un GET porque lo que el usuario busca (los resultados) no se

ve afectado.

respondida el 20 nov. 16 a las 22:10

SJuan76
8,623 4 14 29

No termino de comprender lo de que el GET no tiene un efecto en los datos relacionados.

Dices que es a nivel estándar, ¿puedes añadir alguna referencia a ese estándar? –
Alvaro Montoro ♦ el 20 nov. 16 a las 22:16

@AlvaroMontoro No es que el GET no tiene un efecto, es que no debe tenerlo. Si tienes una
operación que cause un efecto en los datos (por ejemplo, un formulario para cambiar la
descripción de una película), deberías implementarlo como POST. Una operación que no
cause un efecto (consultar la descripción de una película) se puede implementar mediante
GET (se podría mediante POST, pero tendría los inconvenientes arriba mencionados al
navegar, etc.) – SJuan76 el 20 nov. 16 a las 22:18

Si no lo haces así, rompes con la semántica (lo que significa) cada método y los clientes que
se conecten a esos servicios pueden hacerlo ignorando los problemas que causan. Al fin y al
cabo GET y POST no es más que un campo de cabecera de una petición HTTP, la diferencia
es como son tratadas las peticiones según ese campo. – SJuan76 el 20 nov. 16 a las 22:20

Genial. Gracias :) – Alvaro Montoro ♦ el 20 nov. 16 a las 22:21


Al usar este sitio, reconoces
El método GET sehaber leido
utiliza y entendido
para nuestra Política
hacer llamadas HTTP. deSeCookies
utiliza ,para
Política de datos del
obtener

Privacidad , y nuestros
servidor. Se Términos de Servicio
pueden enviar .
parámetros al servidor en la URL de la llamada de la forma:
 
 http://tudominio.com?bar=foo&baz=foo, donde bar y baz son los parámetros y foo los
2
valores en ambos casos. A nivel de mensaje HTTP solo se envía la cabecera. El cuerpo
del mensaje HTTP va vacío.

El método POST se utiliza para enviar información al servidor. A diferencia del GET envía
información del formulario que posteas en el cuerpo del mensaje HTTP.

respondida el 20 nov. 16 a las 19:04

Chamullo
21 1

Te daré la explicación vista desde otro enfoque

Técnicamente puedes utilizarlos indistintamente, persistir información al hacer una

2 llamada GET o consultar información del servidor al hacer una llamada POST. a la final
HTTP es un protocolo de comunicación y no de aplicación así que HTTP en si no te
restringe el uso que le des.

Sin embargo el uso que le debemos dar al protocolo esta normado por una razón y es
que HTTP esta hecho para poder comunicar servidores y clientes indistintamente de la
plataforma (platform agnostic), en un contexto de interconexión sobre el cual se a
montado toda una infraestructura tecnológica, el establecer estas normas facilita la
intercomunicación entre las partes, te permite reutilizar tecnología ya existente, te facilita
el uso de API's expuestas por terceros, o utilizar frameworks/librerias para poder
consumir servicios de terceros o exponer los tuyos.

Los detalles técnicos del tamaño de la petición que debes enviar al servidor al usar tal o
cual método no son tan relevantes, al desarrollar un backend debes pensar que estas
exponiendo recursos y estos recursos serán accedidos por terceros o por tus propias
aplicaciones cliente, al normar que metodos utilizar para leer información GET
(navegación), crear (POST), modificar (UPDATE), eliminar (DELETE), OPTIONS, HEAD
etc. estas dando mayor expresividad a tu API el utilizarla se vuelve mas natural, puedes
reutilizar tecnológia existente como frameworks que te ayudan a generar código genérico
para exponer tus servicios, este código generado utiliza los métodos (GET, POST y
amigos) para exponer tu API. Tu puedes modificar este comportamiento ya que como te
mencioné técnicamente no tienes restricciónes pero si te sales de la norma (del standard)
entonces quedas a tu suerte.

Debes considerar que también esta normado los conceptos de safe e idempotencia para
los diferentes métodos por ejemplo GET es safe e idempotente pero POST no es ni safe
ni idempotente, si no utilizas los metodos según la norma entonces como encajarias safe
e idempotencia en tu API? tendrías que definir que es safe e idempotencia en tu API,
todas las librerías cliente fueron desarrolladas asumiendo todos estos conceptos y
standards y si te sales de la norma como te mencione entonces quedas a tu suerte, si
Al usar este
hacessitio,esto
reconoces
debeshaber leido ytuentendido
parchear API paranuestra
que tusPolítica
normas de se
Cookies , Política
adapten de la
a toda
Privacidad , y nuestros Términos
infraestructura que yadetenemos
Servicio. hoy en día sobre HTTP.
 respondida el 27 dic. 16 a las 21:24
Carlos Lucero
1,178 4 13

Al usar este sitio, reconoces haber leido y entendido nuestra Política de Cookies, Política de
Privacidad, y nuestros Términos de Servicio.