De SOAP a GraphQL pasando por REST: las tecnologías que nos han permitido el desarrollo de APIs
Si eres seguidor de SaaSRadar seguramente habrás notado que hemos abordado recurrentemente el consumo y desarrollo de APIs.
Juntos hemos visto, muy superficialmente, las tecnologías que más se utilizan en la actualidad reflejadas en ejemplos prácticos con código real para desplegarlas.
El objetivo de este artículo es resumir el tema analizando un poco de historia para llegar a la necesidad del surgimiento del desarrollo de APIs y su recorrido hasta las herramientas actuales.
Un poco de historia
En el año 1969 IBM definió GML (Generalized Markup Lenguage) y la ISO lo estandarizó bajo el nombre de Standard Generalized Markup Language (SGML) en el año 1986.
Este estándar nos decía cómo debíamos formatear textos para tener una estructura bien diseñada y mejorar la compatibilidad entre sistemas.
Este estándar es la base de HTML, que surge como una manera de estructurar la presentación de los datos.
Probablemente estes familiarizado con las etiquetas de HTML, que representan la manera de visualizar los datos, mezclando vista y datos en un mismo fichero.
Aquí está la base del problema que hemos presentado todos los desarrolladores al intentar obtener datos de una web.
Dentro de unos pocos años será muy difícil para los desarrolladores más jóvenes visualizar cómo lográbamos hacer funcionar nuestras aplicaciones con una integración entre servicios casi nula.
Teníamos limitaciones importantes en este sentido, diferencias notables entre los lenguajes de programación que hacía prácticamente imposible una integración elegante, y en ocasiones debíamos adentrarnos en técnicas tan inestables como, por ejemplo, parsear una página web para obtener datos necesarios.
En la actualidad el desarrollo basado en servicios como API REST o GraphQL se han convertido prácticamente en estándar necesario para dar un paso más en la integración de sistemas y con este, en el desarrollo de la humanidad.
Yasmani
Ingeniero en Ciencias Informáticas
Necesitamos parsear el HTML creando una fuerte dependencia con la presentación de los mismos, y al primer cambio de presentación de la fuente (digamos que ya no se presentan en una tabla sino en una lista) nuestro código deja de funcionar porque seguimos buscando en una etiqueta de tabla.
La vista y los datos deben ir separados siempre.
De esto se dieron cuenta y en 1999 surge XML (Extensible Markup Language), como un lenguaje de marcas para definir datos, de manera que ya daba igual la manera en que los querías presentar, o si simplemente los manipulabas.
Y en este punto ya estaban todas las condiciones para la era de los servicios web con el desarrollo de APIs.
SOAP
El primer protocolo estándar para servicios web ampliamente difundido por el mundo fue SOAP.
Fue creado por la unión de gigantes encabezados por Microsoft e IBM con el objetivo de servir datos separados de la vista para que cada cliente los analizara o representara fácilmente.
Para el intercambio de la información con SOAP se utiliza el formato XML, de manera que los datos venían del servidor con una estructura bien definida, por ejemplo:
De este modo ya se iba logrando el objetivo, se estaban transportando solo los datos sin información extra para renderizarlos.
La arquitectura de SOAP fue creciendo y complejizándose, llegando a constituir una desventaja.
Para su utilización tenías que manejar además de los datos, otra capa de información sobre esos datos en formato WSDL, donde se especificaba que tipo de información se esperaba y que devolvían cada una de las funciones.
Y sobre estas capas surge otra, UDDI, que funcionaba como un directorio para agrupar la información de cada uno de los WSDL y que otros desarrolladores pudieran localizar tus servicios.
Esta arquitectura se resume de manera general en la siguiente imagen:
En resumen, UDDI para anunciarte el servicio, WSDL para describirlo y XML para transportar los datos.
SOAP se encuentra activo en muchos servicios que forman la base de sistemas ya consolidados y de gran tamaño, pero actualmente la mayoría de APIs que se crean utilizan tecnologías más sencillas como REST.
REST
En el año 2000 se intenta simplificar SOAP y con la tesis doctoral de Roy Fielding surge REST. Se trata un estilo de arquitectura para gestionar datos a través de los métodos HTTP: GET, POST, PUT, DELETE y OPTIONS con un intercambio de datos habitualmente en formato JSON, aunque también soporta XML y YAML.
Con REST se profundiza en las operaciones simples, con un único objetivo y responsabilidad bien definida, minimalismo en su estado puro.
La idea es crear un endpoint por cada recurso a gestionar y atacarlo con peticiones de diferente tipo según la acción a realizar. Si se desea obtener información de realizará un GET, si se quiere crear se utiliza POST, se actualiza con PUT y se elimina con DELETE.
En este caso se muestra una parte de la API para gestionar el recurso Persona, donde se ve claramente como es atacado el mismo recurso /persons con diferentes métodos para realizar las acciones.
Como características fundamentales de REST tenemos:
- Ausencia de estado en el servidor.
- Todas las solicitudes deben declarar si son cacheables.
- Sistema por capas donde el cliente tiene información solo de la capa que le concierne, sin más detalles del servidor o base de datos.
- Separación de responsabilidades.
- Interfaz uniforme.
- Mensajes autodescriptivos.
Uno de los principios fundamentales de REST es que se basa en recursos, con operaciones atómicas, por lo que es necesario utilizar varias llamadas al servidor para hacer consultas grandes donde se requiera unir información de varias tablas.
Este principio debe ser inviolable en REST hasta el punto de no considerar parte de esta arquitectura a las API que por un motivo u otro lo violen.
Es por esta razón que una API de este tipo proporciona una cantidad de endpoint en correspondencia con la cantidad de recursos que se requiera, y dependiendo del software pueden llegar a ser muchos.
Otros de los problemas a los que se enfrenta el desarrollo de APIs con REST es el Over Fetching y Under Fetching, relacionados con la cantidad de datos que devuelve.
TE PUEDE INTERESAR: Cómo realizar el diseño de bases de datos relacionales
Resulta que por lo general una consulta a un recurso devuelve más datos de los que se necesitan por lo que se pierde eficiencia. En otros casos, consultando un solo recurso no se puede obtener toda la información necesaria, por lo que hay que realizar varias consultas para proporcionar los datos necesarios.
El desarrollo de APIs con REST se encuentra muy difundido actualmente. Prácticamente todos los lenguajes cuentan con bibliotecas dedicadas a esta tecnología.
En SaaSRadar lo hemos abordado desde diferentes enfoques. Te invito a que revises nuestra selección de herramientas tanto para consumir como para crear estos servicios.
GraphQL
En el año 2015 Facebook creó GraphQL para enfrentar los problemas reales que presentaban en el funcionamiento de su aplicación.
Un sistema de estas magnitudes requiere un tratamiento especial en cuanto a su optimización, por lo que decidieron crear un nuevo estándar de código abierto diseñado para ser declarativo, flexible y eficiente en el desarrollo de APIs, nacía GraphQL.
Una de las principales diferencias con REST es que en este caso no se trabaja con recursos dedicados. Todos los recursos se consideran un conjunto de grafos conectados entre sí, por lo que es muy sencillo adaptar una consulta a las necesidades de tu sistema y no tener que realizar varias peticiones para obtener los datos necesarios.
GraphQL resuelve los problemas de Over Fetching y Under Fetching que mencionábamos anteriormente en REST. Esta tecnología para el desarrollo de APIs brinda al frontend un lenguaje de consultas de datos que permite definir los parámetros que espera del servidor, evitando el transporte de datos innecesarios.
La cantidad de endpoint también se ve optimizada en GraphQL, al concentrar todas sus funciones en un único punto. Esta característica facilita la creación de abstracciones y generalizaciones en el código, mejorando su usabilidad.
Personalmente creo que GraphQL como tecnología para el desarrollo de APIs y como lenguaje de consulta aun está en proceso de expansión y mejora.
Por las optimizaciones que trae, sobre todo en aplicaciones grandes, pienso que es una tecnología que tendrá mucho futuro y es muy conveniente prestarle una mayor atención.
Si no los has revisado aun, en SaasRadar desarrollamos un ejemplo básico con GraphQL en dos artículos donde implementamos una Consulta y una Mutación, conceptos básicos de esta tecnología de desarrollo de APIs.
De este modo concluimos nuestro repaso por la historia del desarrollo de APIs, donde intentamos mostrar las principales tecnologías que han marcado un antes y un después en el desarrollo, y las de mayor proyección futura.
