HTTP, ese protocolo

Hablábamos antes de que en Internet tenemos una máquina que envía datos a otra mediante una red que sigue el protocolo IP. Y también sabemos que se pueden utilizar varios protocolos a la vez, como IP para la entrega de los datos y XMPP para chatear. Y es aquí donde entra en escena otro protocolo, que muchas veces has escuchado y tecleado, pero que probablemente no te has parado a pensar de qué se trata: el protocolo HTTP (HyperText Transfer Protocol, protocolo de transferencia de hipertexto).

Pongámonos en contexto: el protocolo HTTP fue ideado para intercambiar hipertexto (texto que permite enlazar otros textos mediante enlaces, o sea, que hipertexto es el nombre rimbombante que reciben las paǵinas web). Normalmente las páginas web están alojadas en un servidor web. Un servidor web es un ordenador que está encendido todo el día esperando que alguien le envíe un mensaje pidiendo información. El que pide la información recibe el nombre de cliente.

Con los conocimientos de Scratch que tenemos, podríamos imaginarnos fácilmente cómo podría funcionar el servicio que ofrece el servidor web. Imaginemos que si nos llega un mensaje del cliente que dice dameRecetaGazpacho(), el servidor podría ejecutar esa función en su ordenador, que devolvería otro mensaje con los ingredientes y las instrucciones para realizar un buen gazpacho. Si quisiéramos ajoblanco, entonces la petición podría ser algo así como dameRecetaAjoblanco(). Fácil, ¿no?

Aunque posible, la solución que hemos planteado en el párrafo anterior tiene un problema: para cualquier cosa que queramos tenemos que conocer el nombre de la función. Pongamos el caso de que queremos conocer la receta de la tortilla de patatas... primero tenemos que saber que el servidor ofrece esa receta, y si la tiene, hemos de conocer cómo es la función a llamar porque podría ser dameRecetaTortilla() o dameRecetaTortilladepatatas(). Si la web funcionara así, para cada página que visitemos tendríamos que conocer cómo hacerla funcionar... y, bueno, sabemos que no es así. Navegar por la web es mucho más fácil.

La solución consiste en hacer más sencilla la comunicación entre los ordenadores. ¿Cómo? Pues utilizando un protocolo sencillo. Y la sencillez, entre otras cuestiones, se consigue introduciendo una serie de restricciones, que nos permitan poder seguir haciendo todo lo que queremos, pero no tener que aprender todo. Ese protocolo es precisamente HTTP. La manera ingeniosa que tiene HTTP de ser sencillo y a la vez permitir un gran espectro de posibilidades es mediante dos conceptos: recursos y métodos. Los recursos son un concepto muy amplio, ya que pueden ser cualquier elemento que puedas tener en la red: un documento en un servidor, un servidor, el tiempo de hoy en tu localidad o incluso tu tostadora. Los métodos son los verbos, o sea, las acciones que podemos llevar a cabo. Es en el número de métodos donde se aplica de manera ingeniosa la restricción que hemos comentado con anterioridad, ya que hay unos pocos métodos. Básicamente son los métodos necesarios para meter, sacar, actualizar y borrar - como los protocolos suelen estar en inglés, los métodos son PUT, GET, POST y DELETE.

¿Y con tan pocos métodos (tan poca expresividad que dirían los lingüistas) se pueden realizar tantas acciones? Pues sí, porque los que dan sentido a los métodos son los recursos. Así, si hacemos GET de un documento en un servidor es evidente que lo que queremos es que nos lo envíen. Si en cambio, ese GET es sobre el estante de tomates de la nevera, probablemente lo que queramos es que nos devuelva un tomate (el lector pensará que esto es un poco fantasioso, lo de los tomates y la nevera, pero hay gente trabajando en esto, que se conoce como Internet of the Things o más escuetamente como IoT).

Y así, es como tenemos un protocolo que nos permite interactuar de manera sencilla, sin tener que aprendernos una función para cada nuevo recurso que tengamos en la red.