Diferencias entre GET y POST de HTTP

¿Qué es GET y POST?

Probablemente hayas oído alguna vez de GET y POST sin entender muy bien lo que es. Intentemos aclarar eso antes de entrar en sus diferencias.

Tanto GET como POST son métodos de HTTP. Esto no es algo que es así y ya, sino que se propusieron, fueron aceptados y a día de hoy los utilizamos constántemente, podría haber sido de otra forma, porque, como cualquier protocolo (tanto de la vida como la informática) es sólo un convenio. Para entender un poco más mira el siguiente esquema.

Ejemplo GET

Como se puede ver el usuario hace click en un enlace y Firefox, o el navegador que sea, traduce esa acción en la petición de la página al servidor. Pues bien, en esa petición se utiliza GET. Así que es simplemente una manera de decirle al servidor que haga algo, en este caso que le de index.html para mostrárselo al usuario.

Método GET

Como acabamos de ver GET pide un recurso a un servidor y éste se lo devuelve si lo tiene y puede, o si no da un mensaje de error. No es la intención del tutorial meterse con los mensajes de error, pero como repuesta el GET el servidor da un mensaje 200 si ha ido bien, y si no encuentra lo que pides da un 404, si no sabías de donde venía lo del famoso error 404 aquí lo tienes, es sólo una respuesta a GET.

Lo cierto es que no necesitamos hacer a mano una petición GET, por lo que no tenemos que sabernos su sintaxis, ya lo hacen los navegadores por nosotros, pero para que veas lo sencillo que puede ser mira el siguiente código:

1
2

	GET /index.html HTTP/1.1
	Host: www.ejemplo.com

Lo de después de HTTP es la versión del protocolo, pero básicamente esto le llega al servidor y “entiende” que tiene que devolver index.html. Como puedes imaginar esto no es lo único que mandamos cuando pedimos una página, también mandamos muchos de nuestros datos, desde la codificación de caracteres aceptada, hasta que navegador y sistema operativo usamos. De esa forma el servidor puede hacer una cosa u otra (además de saber a quién tiene que responder, claro). Hay 30 cabeceras (de solicitud) que acepta HTTP, estas son algunas de ellas:

  • Accept. Tipos de datos compatibles, como text/plain.
  • Accept-Charset. Codificación de caracteres que acepta el navegador.
  • Accept-Encoding. Que codificaciones de archivos acepta, como gzip.
  • Cookie. Envía la cookie si ha sido preestablecida antes por el servidor.
  • Host. A dónde se hace la petición, como www.ejemplo.com.
  • User-Agent. Aquí se envía el navegador, la versión y el sistema operativo.
  • Date. Fecha y hora en la que se produce la petición.

Además hay otras cabeceras de respuesta, que el servidor da al cliente, como Server, que indica que servidor es o Set-Cookie, que contiene una cookie para que el navegador la guarde.

En principio se considera que GET es un método seguro, puesto que no afecta al servidor en el sentido de que no cambia nada que tenga, simplemente le pide un recurso y éste se lo da o no. Esa es la principal razón por la que los robots de Google y otros buscadores utilizan este método para analizar Internet.

Método POST

Este método se utiliza mucho también, pero no de la misma forma. Cuando a un servidor le llega un mensaje de POST, analiza el mensaje porque el cliente le ha enviado datos, no solo la URL de lo que quiere más las cabeceras.

Este método se utiliza para subir un archivo a una página, o enviar ciertos datos a través de un formulario, aunque de esto discuteremos después.

Lo importante que nos debe quedar claro, es que si bien GET está pensado para solicitar un recurso, POST está pensado para mandar “algo” al servidor aparte de decirle lo que queremos.

Además, tenemos que pensar en que si el servidor está bien programado el resultado de hacer una petición POST cambiará su estado, la palabra técnica es que no es idempotente, es decir, que si se hace otra vez, el servidor va a cambiar de alguna forma. Para que quede más claro echa un vistazo al siguiente esquema:

Ejemplo POST

Este esquema representa lo que pasa, de manera simplificada, cuando un usuario hace un comentario en un blog con WordPress. Este comentario es enviado a través del método POST y cuando llega el servidor lo almacena en la base de datos. Si se enviara de nuevo el comentario esto afectaría a la base de datos, que tendria otro comentario más.

Pero entonces…¿GET o POST?

Cuando la operación es idempotente -> GET

Como hemos explicado antes idempotente significa que a pesar de que se repita la operación no cambia el estado del servidor.

Por ejemplo: entrar a google.com y al rato entrar de nuevo no cambia nada en los servidores de Google. En cambio si nos registramos si cambia, puesto que en alguna parte de su base de datos noSQL (BigTable, se llama), tendremos un nuevo registro.

Formularios y operaciones no idempotentes -> POST

Soy de la opinión de que todos lo que queramos enviar en formularios se debe hacer a través de POST, explicaré por qué.

Cuando enviamos algo a http://www.ejemplo.com/post.php con POST la URL que vemos es esa, en cambio si lo enviamos con GET quedaría http://www.ejemplo.com/post.php?campo1=contenido&campo2=contenido2, por ejemplo, por tanto resulta más limpio a nivel del usuario y de SEO que las páginas que tengan que recibir más información además de la URL lo hagan por POST.

Existen más métodos

GET y POST son sólo dos de los que existen, hay algunos que casi no se utilizan y que no se conocen mucho, pero forman parte del protocolo HTTP y deberíamos, al menos, saber para qué sirven. Aquí teneís un breve resumen de cada uno:

  • HEAD. Como GET pero solo pide las cabeceras de respuesta, en vez de las cabeceras y el contenido.
  • PUT. Sube al servidor un recurso, lo crea, para entendernos.
  • DELETE. Borra un recurso.
  • TRACE. Envía de vuelta lo recibido del cliente, para que pueda ver si servidores intermedios han alterado el contenido del mensaje.
  • OPTIONS. Devuelve los métodos que soporta el servidor.
  • CONNECT. Convierte la conexión actual a un tunel TCP/IP, normalmente usado para SSL.
  • PATCH. El cliente solicita una serie de cambios en un recurso determinado.

Conclusiones

El objetivo de este post es que quede claro lo que es una operación idempotente, y cuándo usar GET o POST, aunque hay veces que se pueden usar los dos. Aquí dejo una lista de enlaces para más información.

*¿Qué es un RFC?

RFC corresponde a las siglas Request For Comments (Petición de Comentarios) y, básicamente, es un documento que especifica un protocolo en Internet sin ambigüedades, que se sube a la página de RFC oficial. Lo sorprendente es que cualquiera puede hacerlo y si finalmente se acepta puede convertirse en un estándar de Internet.

En general son documentos llenos de detalles bastante aburridos de leer, para qué nos vamos a engañar. Aquí tenéis unos cuántos: TCP, requisitos de un Router y el primer RFC de 1969.