Comparación de API y SOA

Comparación de API y SOA Maximiliano García Santanna Sr. Developer Engineering

Índice

¿Qué es una API? …………………………………………………………………………… 3

¿A qué se le llama API ahora? …….…………………………………………………...…. 4

Surgimiento de SOA ………………………………………………………………………… 5

Surgimiento de API ……………………………………………………………………...….. 7

Plataforma API ………………………….……………………………………………….…... 9

API Gateway ……………………………….…………………………………………………. 9

API Manager ……………………………….………………………………………….……… 11

API Portal ……………………………………..………………………………………………. 13

Usos y características ……………………………………………………………………… 15

Diferencias entre API y SOA .……………………………………………………………… 18

Ventajas de API ……….……………………………………………………………………… 22

Reflexión final …………………...…………………………………………………………… 25

GlobalLogic Inc. www.globallogic.com.ar


¿Qué es una API?

Se define API (del inglés: ApplicationProgramming Interface), como el conjunto desubrutinas, funciones y procedimientos (ométodos, en la programación orientada aobjetos) que ofrece cierta biblioteca para serutilizada por otro software como una capa deabstracción.

Una API representa la capacidad decomunicación entre componentes desoftware. Se trata del conjunto de llamadas aciertas bibliotecas que ofrecen acceso aciertos servicios desde los procesos yrepresenta un método para conseguirabstracción en la programación,generalmente (aunque no necesariamente)entre los niveles o capas inferiores y lossuperiores del software. Uno de losprincipales propósitos de una API consiste enproporcionar un conjunto de funciones de usogeneral. Las API asimismo son abstractas: elsoftware que proporciona la funcionalidad deuna cierta API, es la implementación de esaAPI.

Esto no es nada nuevo, así que la preguntaque surge es ¿A que se le llama API ahora?



¿A qué se le llama API ahora?

Actualmente API es una evolución de SOA, sibien la implementación desde el punto devista tecnológico no tienen grandesdiferencias, es necesario entender elcontexto en el que nace cada uno para poderentender las diferencias. Ambos fueronconcebidos con una orientación y conceptosmuy distintos.



Surgimiento de SOA

SOA surgió como solución en un contexto degran cantidad de conexiones punto a punto.Se ideó enfocado en los proveedores deservicio, con el fin de reducir costos y elesfuerzo de agregar un nuevo consumidor yreutilizar funciones comunes, encapsulandocapacidades en servicios. Cada servicioposee una interfaz y representa unacapacidad, si se quiere acceder a esacapacidad, se debe acceder mediante eseservicio. De esta manera se pueden agregarconsumidores sin modificar la interfaz,ocultando a los consumidores laimplementación, que podría cambiar. Sedefinieron "buenos servicios" desde unenfoque de proveedor: "Esto es lo que tengopara ofrecer".



Los servicios se diseñan con una granularidadmedia, para que con uno se puedan hacerbastantes cosas, pero no demasiadas paraque no sea abrumador, y tampoco muypocas, para que no haya que consumirdistintos servicios para una única necesidad.En este enfoque de proveedor, seconcentraron los esfuerzos en los desafíos deconectividad, para mapear los proveedorescon los consumidores, brindando estabilidady seguridad. Pensado para realizar dos o tresproyectos al año, que reutilizarían lasfunciones encapsuladas y queocasionalmente se debería modificar algo enel back-end de los servicios.



Surgimiento de API

API surge con una realidad mega conectada ycambiante. Cada vez más, los consumidoresse relacionan con los proveedores desdedispositivos o contextos no tradicionales. Elmundo Mobile y Social está creciendoexponencialmente y las aplicaciones mobilepor ejemplo, reciben varias actualizacionespor mes, mucho más rápido que cualquiercosa que se hubiese tenido antes. Estosmedios de interacción, son llamadosSistemas de Compromiso, son dispositivos ycontextos que relacionan y generancompromiso a los clientes con el negocio. Sitratamos de satisfacer esta crecientedemanda de interacción con un enfoque SOA,tendríamos que cambiar constantemente losservicios para añadir las nuevas capacidadese información que los sistemas decompromiso quieren y es muy difícil, noporque técnicamente no se pueda, sino queaumenta la probabilidad de introducir erroresal sistema por la cantidad y la velocidad delos cambios. No se podrían correr todos lostest de regresión a tiempo y no se podríaasegurar la integridad del código.



Estos servicios son el core del Negocio, losque lo mantienen funcionando, así que no sepueden correr riesgos en cuanto a estabilidady disponibilidad de los mismos. Es necesarioencapsular esos sistemas, aun más de lo queSOA lo hace y permitir a los sistemas decompromiso que consuman la información enla forma que quieran, lo más rápido posible,sin hacer modificaciones en el back-end.

Así es como nace API, no como un reemplazoa SOA, sino como un complemento al mismo,para cubrir una demanda más ágil y particular.



PLATAFORMA API

API Gateway

El sistema de gestión de API consta de trescomponentes que se describen en lassiguientes secciones:

A continuación se detallan lasresponsabilidades de este componente.

• La responsabilidad principal es la derealizar la interconexión entre los servicios ylos consumidores, a través de las APIpublicadas en él.

• Ruteo: enrutamiento de mensajes adiferentes destinos en base a un conjunto decondiciones y el contexto del mensaje.

• Soporte de múltiples formatos: esresponsable de la transformación de datos deun formato a otro (JSON y XMLprincipalmente).



• Soporte para múltiples protocolos:debe soportar varios protocolos, tanto para lapublicación de las API como para lacomunicación con los servicios internos.

• Monitoreo: Monitorización del tráfico deentrada y salida.

• Políticas de seguridad: Otorga a las APIautorización, autenticación y cifrado de losmensajes utilizando los estándares detecnologías conocidas (oAuth).



API Manager

A continuación se detallan lasresponsabilidades de este componente:

• La responsabilidad principal esofrecerle a los proveedores de API lacapacidad de configurar y publicar sus API enel componente de API Gateway.

• Publicación: publicar las API en APIGateway, definiendo su punto de entrada(URL por ejemplo) para permitir el acceso almismo.

• Edición: Herramientas para el diseñode la interfaz de la API.



• Control de tráfico: Monitorización deluso de las API, y sistema de configuración decontrol según parámetros del consumo.

• Gestor de políticas de seguridad:Sistema de configuración de seguridad de lasAPI.

• Gestor de ciclo de vida: versionado ydeprecado de las API.



API Portal

A continuación se detallan lasresponsabilidades de este componente:

• La responsabilidad de estecomponente, es la de recopilar toda lainformación necesaria para los consumidoressobre las API publicadas en el API Gateway(Documentación, comunidad, análisis).

• Prueba: Sistema para la prueba de lasAPI.



• Navegador: buscador de las APIregistradas con filtros, como estado, versión,nombre, etc.

• Análisis de uso: Monitoreo y análisis deluso de las API, status de los resultados,tiempo promedio de respuesta, fallos, etc.



Usos y Características

Para las API , la prioridad es lo que quiere elconsumidor. El primer caso de uso que sesuele plantear a la hora de crear una API, es¿qué quiere el desarrollador Mobile de laempresa?



De esta manera, se publica la API y se hacedisponible en el portal de auto-servicio (APIPortal) en el que el desarrollador puedeingresar, encontrar la API, entenderlafácilmente y registrarse para usarla.

Cuando se crea la API, se crean ejemplos deentrada y salida para que pueda ser utilizadoen el desarrollo que estén realizando y asíestar listos para consumirla en muy pocotiempo. Es un enfoque de consumo rápido.

Como el primer caso de uso suele ser eldesarrollador mobile, se tienen que tener encuenta ciertos aspectos. La API debe ser algoque se pueda utilizar en el dispositivo en elque va a correr, un celular o tablet, es decir,algo con batería, así que no puede ser algoque consuma toda la batería, porque estoharía que la aplicación fracase. Tiene que serligera, de granularidad muy fina, para no tenerque buscar en un conjunto grande de datospuntualmente el que se necesita, sino obtenerla respuesta muy rápidamente y sin esfuerzo.



Hay más foco en qué pasa luego deldespliegue, que antes. No se dedicademasiado tiempo de gobierno en tiempo dediseño o en los aspectos de reutilización, laidea detrás de las API, es que no importa si secrea una API por consumidor, porque sonpequeñas, livianas y rápidas de crear.

El objetivo de API siempre es centrado en losconsumidores, por lo que por ejemplo, sepuede implementar para integrar nuevospartners. La mayoría se relacionan con eldiseño pre-existente de SOA, pero un enfoquepara sumar a la minoría restante, es hacerlomediante API.



Diferencias entre API y SOA

Como se menciona anteriormente, entre API ySOA hay similitudes en cuanto a laimplementación tecnológica.



En el mundo SOA los Web Services son muycomunes y también existen tecnologías quesoportan REST, por otro lado APIManagement se implementa principalmentecon REST y también hay soporte para WebServices. Tanto en SOA como en API se hablade consumidores y proveedores y hay algúnnivel de transformación. Entonces ¿Cuál es ladiferencia?

La principal diferencia es el propósito que haydebajo de la tecnología.

Las API son servicios, pero no todos losservicios son APIs. En SOA se encapsulan lascapacidades dentro del sistema y de estamanera se expone todo lo que se puedeproveer. Con API, se intenta hacer lo opuesto,está enfocado en exponer lo que quiere elconsumidor.



Si ya se tiene un gobierno SOA, es un puntode partida perfecto para crear APIs, porque yase cuenta con los servicios que exponen loque se puede proveer, ahora sólo resta pensarque quieren tus consumidores y crear APIsque transformen lo que se puede proveer enlo que se quiere consumir. Esto no quieredecir explotar 100 servicios en 500 APIs,porque eso seguiría siendo una perspectivade proveedor y no de consumidor.

API descarta toda la información que nonecesita de un servicio y ese es el nivel deruteo y transformación que se busca con API,no las transformaciones complicadas que hayen ESB.



En SOA, se invierte gran parte del tiempo degobierno en la etapa de diseño, mientras queen API el gobierno está en administrar lo quepasa luego de que se despliega la API.

En SOA se aplica un proceso robusto degobierno, con metodologías para identificar lagranularidad correcta de los servicios yénfasis en la definición de las interfaces. Porotro lado, API se enfoca en crear y liberarrápidamente las API y enfoca su tiempo degobierno en el ciclo de vida de la misma.



Ventajas de API

Como se dijo previamente, se podría encararesta masificación de sistemas de compromisocon SOA, pero no se contaría con lassiguientes ventajas que se desprenden deluso de API.

• Competitividad: La primera y consideromás importante ventaja es la competitividad.Por ejemplo, existen muchas aplicaciones quecomparan productos, y si se quiere que elnegocio forme parte de esa comparativa, setienen que crear APIs que le permitan a losdesarrolladores, obtener los datos acomparar, rápida y fácilmente, para poderintegrar los datos de negocio, sino se pierdeuna potencial oportunidad de ganar clientes.

• Ampliar visibilidad: Otra de las ventajas,es la de ampliar la visibilidad de la empresa ypor ende un incremento en los clientes,apuntando a negocios que tengan serviciosque se complementen o se puedan relacionarcon los servicios que ofrece nuestro negocio.



Un claro ejemplo me parece MercadoPago.Éste puede ponerse en contacto connegocios en los que haya transacciones dedinero entre dos partes, y ofrecerles su API.

De esta manera, MercadoPago amplía elalcance ganando más clientes y la empresaque lo ofrece como opción, genera una mejorexperiencia de pago para sus clientes,haciendo su oferta más atractiva que la de uncompetidor que no la ofrezca. Es un win-win.

• Tecnologías y mercados emergentes:estar preparado para las distintas tecnologíasy mercados emergentes es fundamental parael crecimiento de cualquier negocio. Latendencia de Internet of Things (Internet delas Cosas), que al igual que Mobile, suelen serartefactos con batería o procesamientolimitados, también se ven beneficiados deluso de API. Un ejemplo podrían ser losequipos de aire acondicionado, que sepueden controlar desde internet.



• Desacoplamiento con la Interfaz:Mediante API se puede separar la interfaz delmodelo de datos y despreocuparse de si se loestá mostrando en un explorador web, unteléfono celular o cualquier otro dispositivoque exista (o vaya a existir), como GoogleGlass.



Reflexión Final

SOA estableció los cimientos para el nuevoenfoque de API, fomentando estándaresabiertos y una cultura orientada a servicios,preparando a la organización para pensar ycolaborar en los propósitos de negocio quevan más allá del silo de la organización.

La industria actualmente no está descartandoSOA. SOA no es una herramienta, es unmarco de trabajo y un modelo de arquitectura.SOA en su estado más puro, sigue vigente, loque cambió es cómo se consumen losservicios en la actualidad debido a nuevasnecesidades en una era de productosorientados al consumidor, para los cuales elenfoque SOA no es totalmente apropiado.

API toma las lecciones aprendidas de SOA yevoluciona el enfoque de orientación aservicios para la realidad de hoy en día.


Software

Comparación de API y SOA