¿Cómo le explicamos REST a nuestros hijos?

Llevo unas semanas analizando cómo simplificar un pequeño sistema que se ha ido creciendo poco a poco hasta resultar bastante complejo. Fruto de este análisis he planteado crear una serie de servicios REST para desacoplar las distintas partes del sistema y poder evolucionar cada componente por separado.

Mientras me documentaba, he localizado varias referencias a un artículo escrito en diciembre de 2004 por Ryan Tomayko en el que, en forma de una conversación con su esposa, explica qué es REST. Desafortunadamente, más o menos a inicios de este año, el propio Ryan Tomayko decidió borrar el artículo porque no se sentía cómodo con una posible interpretación discriminatoria en los roles representados por los dos actores.

Tras una pequeña búsqueda, he logrado encontrar alguna copia del texto para leerlo, en parte por el motivo original de recolectar información y en parte por curiosidad. Borrar un artículo, con el trabajo que supone su creación, por una posible interpretación discriminatoria publicando en su lugar un texto explicando los motivos y pidiendo disculpas no es nada fácil y me parece digno de admiración y respeto.

Tras leer el documento, creo que la interpretación discriminatoria es, cuanto menos, rebuscada: conversaciones similares las he tenido yo tanto con amigos como amigas que no han estudiado informática. Yo tengo un conocimiento un poco más profundo sobre estos temas mientras que cada uno de mis amigos y amigas me dan mil vueltas en bricolaje, calceta, cine, coches, cocina, collages, economía, mecánica, medicina, punto, TV, videojuegos, zapping… son las reglas del juego: todos somos diferentes, nos gustan cosas diferentes y lo que nos hace avanzar es sumar todas esas diferencias.

La forma de explicar el concepto usando una conversación me parece muy amena y descriptiva. Creo que sería una lástima perderlo. Así que he decidido traducirlo e intentar reinventarlo de una forma que es menos susceptible de malinterpretar: unos padres explicándole REST a sus hijos. Evidentemente, se trata de una traducción muy libre y adaptada del texto original.

Niño: ¡Estáis haciendo otra presentación!

Niña: ¿Quién es “Roy Fielding“?

Madre: Un chico muy inteligente.

Niño: Oh ¿qué hizo?

Padre: Ayudó a escribir los primeros servidores web y después hizo un montón de investigaciones explicando por qué la web funciona como funciona. Su nombre aparece en la especificación del protocolo que se usa para descargar páginas de los servidores a tu navegador.

Niña: Y ¿Cómo funciona?

Padre: ¿La web?

Niños: ¡Sí!

Madre: Hmm. Bueno, realmente es todo bastante sorprendente. Y lo gracioso es que está muy subestimado. El protocolo del que estaba hablando papá, HTTP, es capaz de hacer muchas cosas útiles que la gente ignora…

Niño: ¿”HTTP”? ¿Como lo que escribo al inicio de las direcciones en el navegador?

Padre: Sí. Esa primera parte le dice al navegador qué protocolo usar. Eso que escribes es uno de los avances más importantes de la historia de la computación.

Niño: ¿Por qué?

Madre: Porque puede describir la ubicación de algo en cualquier lugar del mundo desde cualquier parte del mundo. Es la base de la web. Podrías considerarlo como si fueran las coordenadas GPS del conocimiento y la información.

Niña: ¿Para páginas web?

Padre: Realmente para cualquier cosa. Ese chico, Roy Fielding habla mucho acerca de a qué apuntan esas cosas en la investigación que os dije. La web está armada en un estilo arquitectural llamado “REST“. REST proporciona una definición de un “recurso”, que es a lo que apuntan esas cosas.

Niña: ¿Una página web es un recurso?

Padre: Más o menos. Una página es una “representación” de un recurso. Los recursos son solo conceptos. Las URLs, eso que escribís en el navegador…

Niños: ¡Sabemos lo que es una URL!

Padre: Oh, ¡Genial! Eso le dice al navegador que hay un concepto en algún sitio. Entonces, un navegador puede pedir una representación específica del concepto. Concretamente, un navegador pide la representación página web de ese concepto.

Niño: ¿Qué otros tipos de representación hay?

Madre: En realidad, las representaciones son una de esas cosas que no se usan demasiado. En la mayoría de los casos, un recurso tiene una única representación. Pero esperamos que las representaciones se usen más en el futuro, porque hay un montón de formatos nuevos apareciendo continuamente.

Niño: ¿Por ejemplo?

Padre: Hmm… Bueno, está este concepto que la gente llama “Servicios Web”. Significa un montón de cosas diferentes para un montón de gente diferente, pero el concepto básico es que las máquinas podrían usar la web igual que la gente.

Niña: ¿Como un robot?

Padre: No, no así. No quiero decir que las máquinas se van a sentar en el escritorio y navegar por la web. Pero los ordenadores podrían usar esos protocolos para mandarse mensajes unos a otros. Hemos estado haciendo eso durante mucho tiempo, pero ninguna de las técnicas que usamos hoy en día funciona bien cuando necesitas hablar con todos los ordenadores en todo el mundo.

Niño: ¿Por qué no?

Madre: Porque no fueron diseñados para usarse así. Cuando Fielding y sus compañeros empezaron a crear la web, ser capaces de hablar con cualquier máquina en cualquier sitio del mundo era de máxima importancia. La mayoría de las técnicas que usamos en el trabajo para hacer que los ordenadores se hablen entre sí no tenían esos requisitos. Tú sólo necesitabas hablar con un pequeño conjunto de ellos.

Niño: ¿Y ahora necesitas hablar con todas las máquinas?

Padre: Sí, y mucho más. Necesitamos ser capaces de hablar con todas las máquinas acerca de todas las cosas que están en todas las demás máquinas. Necesitamos una forma de hacer que una máquina le diga a otra acerca de un recurso que puede estar en otra máquina distinta.

Niño: ¿Cómo?

Madre: Imagínate que estás hablando con tu hermana, y ella te pide prestado tu borrador (o cualquier otra cosa) pero no lo tienes porque se lo has dejado a tu padre. Entonces le dices a tu hermana que se lo pida a tu padre. Esto pasa continuamente en la vida real y también pasa cuando los ordenadores empiezan a comunicarse entre ellos.

Niña: ¿Y cómo se dicen los ordenadores dónde están las cosas?

Madre: La URL, por supuesto. Si todo sobre lo que las máquinas necesitan hablar tiene una URL asociada, tienes el equivalente para una máquina de un nombre. Que tú, yo y el resto del mundo estemos de acuerdo en hablar sobre nombres de cierta manera es bastante importante ¿no?

Niños: ¡Sí!

Madre: Los ordenadores no tienen un nombre universal, por eso dan muchos problemas. Cada lenguaje de programación, base de datos o cualquier otro tipo de sistema tiene una forma diferente de referirse a los nombres. Por eso es por lo que la URL es tan importante: permite que todos esos sistemas hablen unos con otros sobre sus nombres.

Niño: Pero, cuando estoy mirando una página web, no lo veo así.

Padre: Nadie lo hace. Excepto Fielding y unas pocas personas. Por eso las máquinas siguen dando problemas.

Niña: ¿Y qué pasa con los verbos y los pronombres y los adjetivos?😀

Padre: Curioso que lo preguntes, porque ese es el otro gran pilar de REST. Bueno, al menos los verbos.

Niña: ¡Sólo era una broma!

Padre: Parece divertido, pero no es un chiste. Los verbos son importantes. Existe un poderoso concepto en programación y la teoría de las ciencias de la computación que se denomina “polimorfismo”. Es una forma geek de decir que el mismo verbo se puede aplicar a distintos nombres.

Niña: No lo entiendo.

Padre: Bueno… mira a la mesa ¿Qué son nombres? taza, bandeja, periódico, mando a distancia… ahora, ¿qué cosas que puedes hacer con todos esos nombres?

Niño: Yo sigo sin cogerlo…

Padre: Tu puedes cogerlos [1] ¿verdad? Puedes levantarlos. Puedes tirarlos. Puedes quemarlos. Puedes utilizar exactamente todos esos verbos con cualquiera de los objetos que están allí.

Niño: Vale… ¿entonces?

Madre: Bueno, eso es importante. ¿Qué pasaría si en vez de poder decirte “coge la taza” y “coge el periódico” y “coge el mando a distancia” tuviera que utilizar un verbo diferente para cada uno de los nombres? No podría utilizar el verbo “coger” universalmente, sino que tendría que pensar en una nueva palabra para cada combinación de verbo/nombre.

Niña: ¡Guau! ¡Sería rarísimo!

Madre: Sí, lo es. Nuestros cerebros son de alguna manera suficientemente inteligentes para saber que los mismos verbos se pueden aplicar a muchos nombres diferentes. Algunos verbos son más específicos que otros y sólo se aplican a un pequeño conjunto de nombres. Por ejemplo, no puedo conducir una taza y no puedo beber un coche. Pero algunos verbos son prácticamente universales, como coger [GET], poner [PUT] y borrar [DELETE] [2].

Niña: ¡No puedes borrar una taza!

Padre: Bueno, es cierto, pero puedes tirarla a la basura. ¿Es otra broma?

Niña: Sí.

Madre: Entonces, HTTP (ese protocolo que Fielding y sus amigos crearon) es básicamente aplicar verbos a nombres. Por ejemplo, cuando vas a una página web, el navegador hace un HTTP coger [GET] en la URL que has escrito y obtiene una página web.

Padre: Las páginas web normalmente tienen imágenes ¿verdad? Esos son recursos separados. La página web únicamente indica las URLs de las imágenes y el navegador hace más HTTP coger [GET] para ellas hasta que tiene todos los recursos y muestra la página web. Pero lo importante es que todos esos diferentes nombres se pueden tratar de la misma manera. Independientemente de que el nombre sea una imagen, texto, vídeo, música, una presentación, cualquier cosa. Yo puedo coger [GET] todas esas cosas de la misma manera sabiendo su URL.

Niño: Parece que coger [GET] es un verbo muy importante…

Madre: Lo es. Especialmente cuando estás utilizando un navegador web porque los navegadores más que nada cogen [GET] cosas. No hacen mucho más con los recursos. Es un problema porque ha hecho creer a mucha gente que HTTP es solamente para obtener cosas. Pero HTTP es realmente un protocolo de uso general para aplicar verbos a nombres.

Niña: Genial. Pero todavía no veo cómo esto cambia nada. ¿Qué tipos de sustantivos y verbos quieres?

Madre: Bueno, los nombres están ahí pero no en el formato adecuado.

Padre: Imagina que estás navegando por example.com buscando un regalo. Imagina que cada producto es un nombre. Ahora, si estuvieran en un formato que los ordenadores pudieran entender podrías hacer un montón de cosas interesantes.

Niño: ¿Por qué los ordenadores no pueden entender una página web normal?

Madre: Porque las páginas web están diseñadas para que las entiendan las personas. A una máquina no le importan ni la distribución ni el estilo. Las máquinas sólo necesitan los datos. Idealmente, todas las URL deberían tener una representación que pueden entender las personas y otra representación para máquinas. Cuando el navegador coja [GET] los recursos para una persona preguntará por la que entienden las personas.

Niña: Entonces ¿las personas tendrían que hacer formatos para máquinas de todas sus páginas?

Madre: Sí, siempre que fuera interesante.

Padre: Mirad, hemos estado hablando de esto con mucha abstracción ¿Qué tal si usamos un ejemplo real?

Madre: Vosotros sois estudiantes. En la escuela me imagino que habrá un ordenador grande, o más bien tres o cuatro ordenadores, que permiten gestionar a los estudiantes: en qué clases están, qué notas han sacado, contactos de emergencia, información sobre los libros que utilizan, etc. Si los sistemas están basados en la web, entonces probablemente haya una URL para cada uno de los nombres involucrados: estudiante, profesor, clase, libro, aula, etc.

Padre: Muy bien, accediendo con el navegador a cada URL obtendremos una página web. Si hubiera un formato legible por máquinas para cada URL, entonces sería trivial añadir nuevas herramientas en el sistema porque toda la información puede consumirse de la misma forma. También sería bastante más fácil para cada uno de los sistemas hablar con los otros. O podrías construir un sistema provincial o nacional que sería capaz de hablar con cada una de las escuelas individuales para obtener las notas. Las posibilidades son infinitas.

Madre: Cada uno de los sistemas podría obtener información de los otros utilizando simplemente HTTP coger [GET]. Si un sistema necesita añadir algo a otro, podría utilizar un HTTP publicar [POST]. Si un sistema necesita actualizar algo en otro sistema, utilizará un HTTP [poner] PUT. Lo único que falta es saber la pinta que tienen los datos.

Niño: ¿Entonces es en esto en lo que vosotros y toda la gente de ordenadores está trabajando? ¿Definir la pinta que los datos deberían tener?

Padre: Desgraciadamente, no. La gran mayoría está ocupada escribiendo capas de complejas especificaciones para hacer este tipo de cosas de una manera diferente que no es ni remotamente tan fluida o útil. Los nombres no son universales y los verbos no son polimórficos.

Madre: Estamos tirando a la basura décadas de uso en entornos reales y técnicas probadas y empezando de cero con algo que se parece mucho a otros sistemas que ya han fallado en el pasado. Usamos HTTP pero sólo porque nos ayuda a hablar menos con los encargados de redes y seguridad. Cambiamos la simplicidad por llamativas herramientas y asistentes.

Niños: ¿Por qué?

Padre: No tengo ni idea.

Niños: ¿Por qué no decís algo?

Padres: Quizá lo hagamos…

Notas:
[1] Se ha intentado conservar el chiste incluido en la versión original.
[2] El artículo original juega con los verbos definidos en HTTP (GET, POST, PUT, DELETE) que son utilizados habitualmente en inglés. Cuando esto suceda, se incluirá el verbo definido en HTTP entre corchetes.