Search for a command to run...
(o Cómo surgieron las APIs RESTful)
I am a software developer with more than 10 years working in the field of web development. I'm starting to dive into the world of mobile development and data science.
I love learning new stuff and I do believe that teaching/sharing what you know is one of the best ways to reinforce what you learn.
No comments yet. Be the first to comment.
En esta serie compartiré todo mi conocimiento sobre las APIs RESTful: desde qué son hasta cómo funcionan.
¿Estás empezando en el mundo de la programación web? ¿Has escuchado sobre las APIs RESTful? Como profesionales del desarrollo web, debemos tener un conocimiento sólido sobre las APIs RESTful, pues estas se han convertido en una herramienta fundamental para crear aplicaciones web en la actualidad.
En esta serie compartiré todo lo que sé sobre APIs RESTful: desde qué son y cómo surgieron, hasta cómo trabajan y por qué resultan convenientes para desarrollar cualquier tipo de aplicación web.
Si deseas crear APIs o sacar el mejor provecho de las APIs ya existentes, ¡te invito a que sigas leyendo!
En la década de los 90s, el número de usuarios navegando la web aumentó drásticamente. Internet era el nuevo chico en el barrio ¡y todos lo amaban!
Todos, excepto los programadores.
El desarrollo de sitios web de propósito general se convirtió, de un momento a otro, en una ocupación demandante. Más temprano que tarde, el crecimiento acelerado del ecosistema web dejó ver un problema importante: en aquel momento no existían maneras bien definidas, estandarizadas, de construir y comunicar aplicaciones a través de Internet.
Afortunadamente, algunas personas comenzaron a atacar este problema, consolidando algunos de los estándares fundamentales de la web. Una de estas personas, Roy Thomas Fielding, quien fuera parte del equipo que definió los estándares de HTTP 1.0 y 1.1, comenzó a trabajar en una tesis sobre un estilo arquitectónico para construir y comunicar sistemas en Internet.
Comienza REST.
Fielding presentó su disertación "Architectural Styles and the Design of Network-based Software Architectures" en el 2000. Ahí, definió el estilo arquitectónico de Transferencia de Estado Representacional (REST, por sus siglas en inglés) como un conjunto de reglas: una especie de guía para diseñar y construir sistemas sobre Internet.
Podríamos decir que REST define cómo hacer las cosas (un estilo arquitectónico) en lugar de representar una implementación por sí mismo.
Cualquier pieza de software que siga (todas o la mayoría de) las reglas definidas por REST (es decir, cualquier implementación de REST) es... redoble de tambores... ¡RESTful!
Pero, ¿cuáles son esas dichosas reglas definidas por REST? ¡Me alegra que lo preguntes! Hablemos, entonces, sobre las 6 reglas que toda implementación de REST debe seguir:
Cliente-Servidor. Este es nuestro punto de partida: cómo debe ser la arquitectura. Siguiendo una arquitectura Cliente-Servidor, debemos separar las tareas relacionadas con la interfaz de usuario (el cliente) de las tareas del almacenamiento de datos (el servidor). Esta separación permitirá a cada componente (cliente o servidor) evolucionar de manera independiente, aportando, por lo tanto, portabilidad y escalabilidad.
Carencia de Estado. Habiendo definido una arquitectura cliente-servidor, esta segunda regla indica que la comunicación entre el cliente y el servidor debe carecer de estado: cada petición hecha por el cliente debe contener toda la información que el servidor necesite para procesarla. Las peticiones no deben depender de ningún contexto en el servidor: deben de ser independientes.
Caché. Como un buen complemento a la comunicación carente de estado entre clientes y servidores, esta regla nos permite etiquetar a un recurso regresado por el servidor como cacheable o no cacheable. Un recurso cacheable puede ser reutilizado sin problema por el cliente para peticiones idénticas en el futuro. Esto permite un incremento en la velocidad y la eficiencia al reducir las interacciones con el servidor.
Interface Uniforme. Esta es la regla que realmente diferencia a REST de otros estilos arquitectónicos. Básicamente nos dice que, sin importar qué recurso provea el servidor, siempre debe existir una interface uniforme que defina cómo son presentados esos recursos y, por lo tanto, cómo deben ser consumidos por el cliente. Esta interface uniforme queda definida, a su vez, por 4 reglas:
Sistema por capas. Esta regla nos permite romper la arquitectura en capas separadas, cada una a cargo de una tarea en específico. Cada capa es independiente y no tiene conocimiento del sistema más allá de la capa aledaña con la que interactúa: son independientes. Con esto en mente, podemos tener una capa que maneje la autorización, por ejemplo; otra encargada del balanceo de carga y así sucesivamente. Esto permite aumentar la portabilidad y escalabilidad para cada componente del sistema.
Código bajo demanda. Esta última regla es opcional. Le permite al cliente extender su funcionalidad descargando y ejecutando código en la forma de applets o scripts. Esto permite al cliente ser más ligero al reducir las funcionalidades implementadas directamente por él.
Ahora que entendemos mejor lo que RESTful significa, estamos listos para hablar sobre APIs, APIs RESTful.
¡Casi estamos listos!
Ahora que tenemos una mejor idea de lo que es REST y lo que significa RESTful, sólo nos queda un concepto por revisar: ¿qué es una API?
Una Interfaz de Programación de Aplicaciones (API, por sus siglas en inglés) es un conjunto de reglas que definen cómo deben comunicarse dos piezas de software. Podemos definirla como una especie de contrato que cada parte debe seguir para poder transferir datos entre ellas.
¡Genial! ¡Ahora tenemos una idea clara de todos los conceptos que necesitamos para definir una API RESTful!
Aquí va una sencilla definición:
Una API RESTful es una manera de comunicar dos aplicaciones en Internet bajo las reglas definidas por REST. Dicho de otro modo, las APIs RESTful definen la manera en la que los servicios web deben exponer sus recursos y cómo los clientes deben consumir dichos recursos en Internet.
Entonces, aunque no se trata propiamente de un estándar, esta implementación de REST en la forma de APIs representó una solución al problema de comunicar dos aplicaciones en Internet. No fue la única solución, cabe aclarar: ya se hablaba de SOAP, por ejemplo, cuando las APIs RESTful apenas aparecían. Sin embargo, esa es una historia para otro artículo...
Para la siguiente entrega de esta serie planeo hablar más a fondo de cómo funcionan estas APIs: escribiré a detalle sobre cómo implementan las reglas definidas por REST mencionadas anteriormente, incluyendo conceptos como recursos, métodos HTTP, etc. para que te sea más fácil construir tu propia API RESTful o consumir alguna existente.
Finalmente, terminaré esta serie con una breve conclusión sobre por qué las APIs RESTful son tan relevantes en la actualidad. ¿Deberías usarlas siempre o no?
...
Espero que este artículo te haya sido de utilidad para entender mejor el concepto de una API RESTful. Cualquier comentario o duda al respecto, déjamelo saber en los comentarios. De igual manera, si hay algún tema sobre el que te gustaría que escribiera, no dudes en hacérmelo saber.
¡Muchas gracias por leer hasta aquí! ¡Que tengas un excelente día!
Todas las imágenes utilizadas en este artículo, incluyendo la portada, fueron diseñadas específicamente para este blog por Zafiro Luna.
