No tienes que creerme, puedes comprobarlo tú mismo. La búsqueda API Management en Google devuelve casi 7 millones y medio de resultados. Todas las compañías de referencia tienen sus APIs para desarrolladores (Facebook, Google Maps, Twitter…) y empresas de sectores más tradicionales y reticentes a publicar sus datos o servicios online, como la banca, están inmersas en una carrera por ser los primeros en posicionarse. Y hablamos de gigantes como Citi o BBVA.
En esta web puedes obtener información acerca de la evolución histórica de las APIs desde el año 2.000. Es muy interesante para tener una perspectiva de cómo iniciativas independientes han creado una tendencia generalizada.
Después de toda esta charla deberías estar haciéndote la siguiente pregunta: ¿son las APIs algo «importante» o una nueva moda pasajera? Si te decantas por la primera opción sigue leyendo, intentaré aportar algo de claridad sobre este tema.
¿Qué es un API?
La pregunta del millón y la primera que debemos hacernos. Podemos tratar temas realmente interesantes como «API Management», «API Governance» y «API Economy», pero antes deberíamos saber qué es un API.
Si nos ceñimos al concepto puramente técnico API son las siglas de Application Programing Interface (Interfaz de Programación de Aplicaciones). Resumiendo mucho, un API es la exposición de una operación o función para su uso externo o interno.
Además existen una serie de características o cualidades sobre la forma en la que se expone dicha función. Unos autores hablarán de estas propiedades como exigidas (uso de verbos http, uso de JSON, principios de HATEOAS) y otros las etiquetarán simplemente como «deseables».
Como en la mayoría de los casos, habrá discusiones y múltiples opiniones al respecto, aunque se ha llegado a un cierto acuerdo sobre las cualidades fundamentales.
«Estupendo, un párrafo pseudo-técnico muy bonito, pero sigo sin saber qué es un API» estarás pensando.
Bien, dejemos a un lado los aspectos técnicos. Un API es una forma de exponer tus datos, tus funcionalidades y en definitiva tu negocio, al mundo, permitiendo que otros puedan hacer uso de ellos.
«Y ¿por qué querría exponer mi negocio al mundo? Me parece algo peligroso y además ya tengo una web para que la gente me conozca».
Por supuesto conlleva un riesgo, pero como veremos la seguridad es una parte fundamental del API Management.
¿Por qué un API?
Piensa por un momento en tu negocio actual. Estoy seguro de que tu web cumple su función y probablemente fue un notable impulso a tu negocio en su momento, pero, ¿cuánto más puedes innovar por tu cuenta? Porque al fin y al cabo de esto se trata, de innovar. Si no renuevas tu negocio, si no revisas constantemente lo que haces, cómo lo haces y si no te preguntas qué cosas nuevas podrías hacer, es probable que tu negocio no vaya tan bien dentro de unos años.
Para evitar esto puedes hacer varias cosas.
- Invertir en I+D. Puedes reunir a un grupo de personas muy preparadas, encerrarlas en una habitación y pedirles que innoven todo lo que puedan pero… ¿Es ese un buen ecosistema para la innovación? ¿Puede competir con la cantidad de nuevos talentos e ideas que surgen cada día? ¿Tienen las herramientas adecuadas? La respuesta más realista es no, pero supongamos que puedes reunir a los mejores, un equipo realmente talentoso y productivo, ¿pueden cubrir todos los casos imaginables? Si algo nos ha mostrado la era digital es que continuamente surgen nuevas formas de tratar los datos, nuevas ideas para explotarlos y generar beneficios.
- Abrir tu negocio a terceros. Tus datos son tuyos, tus procedimientos son tuyos, pero puedes dejar que otros los utilicen y obtener un beneficio de ello (ya hablaremos de monetización de las APIs, un concepto malinterpretado en ocasiones).
Para eso sirven las APIs. Un API no es más que un servicio que ofreces a otros a través de Internet siguiendo las normas y buenas prácticas de las programación de APIs. Mediante las APIs expandes tu negocio, llegas a más clientes potenciales y facilitas que se generen nuevas ideas sobre él, de las que obtendrás beneficio de una forma u otra.
«¿Has dicho ‘servicio’ ?… eso suena a SOA y conozco muchos proyectos en los que SOA fue un fracaso».
Pues sí, tienes razón. SOA y APIs son algo así como primos lejanos. O no tan lejanos porque siguen los mismos principios. Y también tienes razón al decir que muchos proyectos para transformar una organización al paradigma SOA fueron un fracaso… y otros un éxito. Si una gran idea, como SOA, no llega a buen puerto no debemos culpar a la idea. Seguramente deberíamos analizar cómo se puso en práctica para encontrar los motivos del fracaso. Las arquitecturas orientadas a servicios son una grandísima idea, aunque a veces se apliquen incorrectamente o donde simplemente no encajan. No disparemos al mensajero.
SOA vs APIs
El primer paso para llegar al éxito en la implementación de un API es identificar y aislar los procesos de negocio. Debemos reconocer las funcionalidades que ofrece nuestro sistema y «empaquetarlas» de forma que puedan ser reutilizadas. Este es un paso común en la filosofía SOA y API. Si intentas «APIficar» tu negocio sin elaborar una lista de los procedimientos existentes y sin evaluar su grado de «servicio», vas a encontrar muchas piedras en el camino.
El siguiente paso es implementar las funcionalidades que queremos ofrecer como servicio. Aquí aparecen las primeras diferencias.
El paradigma SOA se cimentó fundamentalmente en SOAP (Simple Object Access Protocol), un protocolo con muchas virtudes y con unos cuantos defectos. No realizaré una exposición de ventajas y desventajas de SOAP, pero nombraré dos características que han potenciado el uso de REST+JSON frente a SOAP+XML en el «movimiento API».
- Tamaño: los mensajes SOAP son pesados o al menos no son tan ligeros como nos gustaría. Contienen muchísima información de cabeceras, espacios de nombres y otra información que puede resultar necesaria o innecesaria.
- Complejidad: el formato SOAP no es muy amigable en su lectura o al menos no tanto como JSON. Los ficheros xsd no son precisamente «human readable».
Por estos (y otros) motivos el desarrollo de APIs se ha cimentado sobre la unión de dos tecnologías, REST y JSON, buscando un mecanismo ligero y probado. Ligero porque hoy en día gran parte de los accesos a Internet se realizan desde dispositivos móviles con una capacidad de computación limitada, así que más ligero = más rápido. El uso de REST (Representational State Transfer) garantiza un protocolo ampliamente testado, con años de uso y también ligero. Sin entrar en detalle, cada mensaje HTTP contiene toda la información necesaria para realizar la operación, evitando almacenar estados en cliente o servidor (aunque no todo lo que hoy se llama REST cumple esta norma).
A partir de este punto, las diferencias se hacen más notables.
Ambas aproximaciones cuentan con mecanismos de seguridad (WS-Security para SOAP, OAuth para REST) y en ambas es posible realizar una monitorización de los servicios. Si embargo en SOA estos aspectos se tratan como parte de la implementación técnica de la solución ajenos al paradigma, mientras en APIs son una parte fundamental de la filosofía.
Para terminar he reservado la que posiblemente es la mayor diferencia de todas. La comunidad. El paradigma SOA no hace alusión alguna a la manera de dar a conocer nuestros servicios. Los servicios se definen y se implementan. Punto. Si alguien quiere usarlos deberá obtener la información del servicio realizando las preguntas adecuadas a los actores adecuados. Por el contrario, la filosofía API establece una serie de cualidades fundamentales para favorecer el uso de las APIs, llegando incluso al concepto de «comunidad». No es suficiente ofrecer el API, es necesario crear un entorno que facilite su uso y publicite su existencia.
Dicho entorno debe ofrecer:
- Uso sencillo de las APIs, con documentación detallada y de fácil comprensión para el consumidor del API.
- Autoservicio, permitiendo a los potenciales consumidores explorar y utilizar las APIs sin necesidad de complejos procesos de suscripción. La suscripción debe ser un procedimiento autónomo.
- Gestión de cuentas. El uso de las APIs debe estar regulado en base a permisos y cuotas de usuario.
- Comunidad, favoreciendo la comunicación propietario-consumidor de API.
- Estadísticas de uso que permitan dimensionar las APIs y controlar el consumo por parte de los usuarios.
La gestión de este entorno es lo que definimos como API Management y será un tema a tratar en próximas publicaciones.