Arquitectura y estrategia de API Un enfoque coordinado

Introducción El auge de la interfaz de programación de aplicaciones (API por sus siglas en inglés) representa una oportunidad de negocio y supone un reto técnico. Para los líderes empresariales, las API representan una oportunidad para abrir nuevos flujos de ingresos y maximizar el valor ofrecido al cliente. Sin embargo, los arquitectos empresariales son los encargados de crear las API que posibilitan la reutilización de sistemas back-end en las nuevas aplicaciones web y móviles.

Los arquitectos, por su parte, deben responsabilizarse del mantenimiento de un enfoque claro de dichos objetivos a lo largo del proceso de implementación de la infraestructura de una API y el diseño de la interfaz en sí. Todas las decisiones técnicas deberán contribuir a la creación de una interfaz que permita a los desarrolladores crear aplicaciones de cliente que resulten de gran valor para los usuarios finales.

Resulta esencial que todos los implicados comprendan que los objetivos de negocio y los retos técnicos de un programa de API están estrechamente relacionados. Los gestores de los programas deben responsabilizarse de comunicar con claridad los objetivos de negocio clave de una API propuesta a los arquitectos que deberán construir la interfaz.

Este libro electrónico destaca las prácticas recomendadas para el diseño de API centradas en los resultados que conformarán la base del éxito de su programa de API.

2

Parte 1: De SOA a API La TI empresarial del siglo XXI se ha caracterizado por un avance en cuanto a la apertura de bases de datos y aplicaciones antiguamente aisladas en contenedores, de manera que los datos y las funciones resulten accesibles más alllá del perímetro de la organización o se puedan reutilizar en sistemas nuevos. La manifestación inicial de esta tendencia fue la arquitectura orientada a servicios (SOA por sus siglas en inglés) y la más reciente ha sido el auge de las API orientadas a la Web. En cierto sentido, los “servicios web” centrales de SOA representan el mismo concepto de las API de la Web. Se trata de interfaces empleadas para abrir sistemas back-end. Sin embargo, hay ciertas diferencias básicas entre ambas tecnologías, que resultan de gran relevancia para las decisiones de diseño básicas: •

•

•

La diferencia técnica principal es que los programas SOA se centran en la creación de servicios web para facilitar las integraciones internas y entre servidores, mientras que las API de la Web surgen para acelerar la creación de aplicaciones basadas en móviles y la Web, y a menudo están en contacto directo con el cliente. Los programas SOA suelen surgir en los departamentos de TI y se centran en el ahorro de costes, pero los programas API suelen diseñarse en organizaciones de desarrollo empresarial y se centran en la generación de ingresos nuevos.

Ilustración 1: SOA en comparación con las API

$$$

La mayoría de los programas SOA los crean arquitectos empresariales para arquitectos empresariales con el objetivo de integrar con mayor facilidad sistemas heterogéneos y ofrecer servicios de TI nuevos. Los programas API, por su parte, deberían centrarse en cubrir las necesidades de los desarrolladores de aplicaciones. 3

SOA

API

Objetivo de integración

Interna o para partners

Externa, a menudo para clientes

Elemento impulsor del proyecto

Costes de TI

Ingresos para el negocio

Consumidor de la interfaz

Arquitectos empresariales

Desarrolladores de aplicaciones

Parte 1: De SOA a API

Objetivos del diseño de API Sin embargo, muchos programas API han evolucionado a partir de iniciativas SOA anteriores. Los servicios web centrados en integraciones internas o con partners se están ampliando a los desarrolladores, tanto dentro como fuera de la empresa. Durante este proceso, es importante que los diseñadores de API no olviden que un programa API presenta motivos y requisitos distintos de los que inicialmente llevaban a las empresas a ampliar sus activos de TI a través de servicios web. Con este dato en mente, los amplios objetivos del diseño de API en general se pueden definir del modo siguiente: •

Ofrecimiento de autoservicio para desarrolladores y usuarios de aplicaciones

•

Reducción de barreras de acceso a valiosos recursos empresariales

•

Priorización de las necesidades y preferencias de los desarrolladores de aplicaciones de clientes

•

Fomento de la colaboración entre recursos internos y externos

•

Enfoque de los problemas de seguridad y escalación derivados de la exposición de los activos de TI al mercado abierto

Lo más importante de todo es que el diseño de API debe centrarse en la maximización del valor de negocio de la interfaz. En la parte 2, se detallará con mayor profundidad cómo las API agregan valor al negocio.

4

Parte 2: La cadena de valor de las API Puede que las API no posean ningún valor intrínseco, pero sí aportan un gran valor al negocio. Para ello, emplean los datos back-end y las funciones de la aplicación que ofrece la interfaz. Con este enfoque, la API es, simplemente, un método que ayuda a la reutilización de sistemas con un gran valor organizativo en aplicaciones que tienen más probabilidades de ofrecer un valor empresarial directo.

potencial de dichos activos. Podemos denominar este estado del negocio como “cadena de valor de las API”. Resulta importante comprender que una API ofrece valor de este modo relativamente complejo porque, si no, resultaría muy sencillo perder de vista el hecho de que las API existen para ofrecer un valor de negocio y no eficiencia técnica. No obstante, aunque las API ofrecen valor de un modo más directo que la SOA, lo hacen de un modo más indirecto que la Web basada en exploradores, donde un sitio puede ofrecer ventas o captar clientes. Las API generan ingresos de un modo más sutil, a través de la conexión de diferentes activos que se indican más abajo.

Aunque se trata de una perspectiva útil, si se analiza con más detalle, resulta evidente que una API bien diseñada es, de hecho, un sistema de conexión complejo y potente. Reúne una amplia variedad de activos empresariales (sistemas de TI, personal interno y externo, clientes y aplicaciones de cliente) para descubrir de un modo más eficaz el valor Ilustración 2: La cadena de valor de las API

Sistemas back-end

Proveedores de API

Desarrolladores de aplicaciones 5

Aplicaciones de cliente

Usuarios finales

Parte 2: La cadena de valor de las API

Algunos ejemplos de cómo general valor las API Cada API tendrá su propio valor exclusivo. En términos generales, las empresas podrán emplear una API para realizar lo siguiente: Generar nuevos ingresos de forma directa Una API puede ser una fuente de ingresos directa si se cobra el acceso a los desarrolladores o si la interfaz se emplea para facilitar la creación interna de aplicaciones por las que hay que pagar o para habilitar el comercio electrónico. Ampliar el alcance y el valor de cliente Las API simplifican el proceso de captación de clientes nuevos o de aumento del valor de los clientes actuales al ofrecer servicios existentes mediante dispositivos y plataformas nuevos. Admitir actividades de marketing y ventas Una API también puede ayudar a una empresa a comercializar sus productos y servicios mediante la posibilidad de crear funciones envolventes y atractivas relacionadas con las prácticas recomendadas del marketing en línea. Estimular la innovación empresarial y técnica Las API ayudan a las empresas a desarrollar nuevos sistemas, ofertas y estrategias, ya que reducen los límites de las innovaciones al posibilitar la implementación de ideas sin modificar los sistemas back-end.

6

Parte 2: La cadena de valor de las API

Toma de decisiones sobre el diseño La toma de decisiones sobre el diseño de las API deberá basarse en lo que conectará exactamente la API (qué habrá a cada lado de la interfaz), tanto dentro de la infraestructura de la TI organizativa como fuera del cortafuegos de la empresa. En especial, resulta esencial responder a estas dos preguntas: • •

¿Qué sistemas se van a exponer y dónde (y con quién) se encuentran? ¿Quiénes son los desarrolladores objetivo y qué tipo de aplicaciones construyen?

Los programas de API abiertas suelen centrarse en la adopción. Al permitir a desarrolladores de terceros acceder a sus API, las empresas pretenden ofrecer sus activos de TI a la base de usuarios más amplia que puedan. Por lo tanto, la adopción por parte de los desarrolladores es una métrica clave para calcular el éxito de una API abierta. Aunque hay menos API abiertas que privadas, son las abiertas las que generan las mayores oportunidades de negocio y las que presentan los riesgos técnicos y retos de diseño más importantes.

Esta última pregunta es especialmente importante y resulta relevante para el método más básico de clasificación de una API: “privada” o “abierta”. Las API privadas se emplean únicamente en la empresa o, en ciertos casos, por parte de organizaciones de partners. Las API abiertas se ponen a disposición de una comunidad más amplia de desarrolladores externos que tienen libertad para crear sus propias aplicaciones mediante los recursos back-end de la empresa.

De hecho, las API abiertas no solo crean diversos retos de diseño de integración completamente nuevos (por ejemplo, cómo abrir sistemas back-end para desarrolladores externos sin exponer dichos sistemas a piratas informáticos), sino que también generan nuevos riesgos empresariales. Un programa de API abierta con un diseño deficiente puede hacer que una empresa destroce su propio negocio principal y puede exponer los activos fundamentales de la empresa ante la competencia.

Las API privadas se parecen más a los servicios web. Normalmente, el objetivo de una API privada es el de ayudar a los desarrolladores, contratistas o partners internos a crear aplicaciones de un modo más eficiente para su uso interno o externo. Al igual que ocurre en el caso de los servicios web, la reducción de los gastos suele ser el motivo principal, ya que las API permiten desarrollar aplicaciones nuevas de manera rentable. No obstante, muchas API privadas se emplean para crear aplicaciones web y móviles orientadas al público que generan un valor de negocio nuevo de forma más directa.

Estos tipos de consideraciones empresariales son en los que deben basarse las decisiones de diseño técnico. En la parte 3, se explicará cómo alinear las consideraciones empresariales con las decisiones técnicas.

7

Parte 3: Alineación del diseño de las API con los objetivos de negocio Aunque la SOA, históricamente, ha buscado la mejora de los procesos organizativos, los programas de API pretenden aumentar los ingresos empresariales. Por lo tanto, las decisiones de diseño de las API deben centrarse claramente en los objetivos de negocio estratégicos principales del programa de API de la empresa. Antes de comenzar el diseño de una API, debe tener claro qué problemas desea que solucione el programa de API, qué oportunidades desea aprovechar y cómo lo va a hacer. En especial, es importante responder a estas preguntas: • • • • •

¿Qué activos estarán disponibles? ¿Cómo debería funcionar la API para que dichos recursos estén disponibles? ¿Qué tipo de aplicaciones se podrían construir basándose en la API? ¿Cómo motivar a los desarrolladores para utilizar la API? ¿Cómo hacer para que las aplicaciones creen valor para el negocio?

La comunicación y la colaboración son elementos clave para el diseño de una API que afronte estos retos y oportunidades. A lo largo del proceso de diseño, implementación y gestión de una interfaz, los gestores de programas y los arquitectos de API deben trabajar en estrecha colaboración para acordar los objetivos estratégicos principales, qué harán para alcanzar dichos objetivos y cómo evaluarán los resultados de sus esfuerzos. En concreto, los cometidos técnicos y empresariales deben estar de acuerdo en los aspectos siguientes: • •

El estado final objetivo e ideal del programa Las tareas iniciales que permitirán a la organización trabajar para lograr estos objetivos Las métricas clave que se emplearán para calcular el éxito Las tareas diarias continuas que permitirán al programa seguir alcanzando objetivos

• •

8

Parte 3: Alineación del diseño de las API con los objetivos de negocio

Asignación de un patrocinador Para asegurarse de que los arquitectos y los gestores empresariales estén de acuerdo, el programa debe disponer de un “patrocinador” que pueda abarcar las divisiones que a menudo aparecen entre departamentos técnicos, gestores empresariales y desarrolladores de aplicaciones. Las organizaciones suelen cometer el error de asignar este cometido a un gestor de marketing sin conocimientos técnicos, pero este “gurú de API” debe ser capaz de comprender las limitaciones arquitectónicas de la organización y compartir el entusiasmo de los desarrolladores de aplicaciones. Su cometido es establecer una comunicación fluida con todos los implicados y, en especial: •

“Vender” el programa de API a ejecutivos y otros responsables superiores de la toma de decisiones.

•

Asegurarse de que los arquitectos de API comprenden los objetivos de negocio de los gestores de programas

•

Ayudar a los gestores de programas a comprender las limitaciones y los recursos técnicos de los arquitectos

•

Recopilar información sobre las preferencias y los requisitos de los desarrolladores objetivo

Ilustración 3: Alineación de objetivos de API Líderes empresariales Gestor de programas API

Desarrolladores objetivo Gurú de API

Oportunidades de ingresos

Arquitecto de API

Recursos técnicos Objetivos Tareas Métricas

Una vez que se haya establecido la comunicación y se hayan acordado los objetivos, las tareas y las métricas, puede comenzar el trabajo real de diseño de API, que es lo que se va a describir en la parte 4. 9

Parte 3: Alineación del diseño de las API con los objetivos de negocio

Notas sobre la estrategia de negocio de las API Los gestores de programas (o “propietarios de API”), en colaboración con el gurú de API, deben responsabilizarse del diseño de una clara estrategia de negocio de API y de la comunicación de dicha estrategia a los responsables de la toma de decisiones en el ámbito ejecutivo, así como a los arquitectos y desarrolladores que se encargarán del aspecto técnico de la estrategia. El primer paso consiste en establecer un objetivo de negocio claro y establecer un plan para el programa de API que se alinee con el enfoque general de la empresa. Una API no es una solución puramente técnica y debe tratarse como un producto o una estrategia de negocio en sí misma, aunque siempre se incluya dentro del marco de la estrategia de negocio general de la empresa. Con esto en mente, el paso siguiente consistiría en crear un modelo de negocio en torno a este enfoque, en el que se deberán destacar los detalles siguientes: Costes, recursos y eficiencias • Los sistemas, las relaciones, las actividades y otros recursos que aprovechará el programa, y cómo este permitirá a la empresa realizar un mejor uso de dichos recursos. Valor, ingresos e innovación • Los clientes, los mercados y los canales a los que se dirigirá el programa, así como el modo en que la innovación técnica permitirá generar nuevos ingresos a partir de dichos objetivos. El núcleo de este modelo de negocio debería ser una propuesta de valor que destaque claramente el valor de negocio real y verificable que ofrecerá el programa de API a la empresa.

10

Parte 4: Diseño de una API operativa Desde un punto de vista puramente técnico, el diseño de una API es relativamente sencillo. Sin embargo, el diseño de una que contribuya a aumentar el valor real del negocio puede complicar el asunto. Aparte de la funcionalidad, los arquitectos de la empresa también deben tener en cuenta los objetivos de negocio y la experiencia del usuario final. Esto puede suponer un reto especialmente duro para quien desee ampliar un proyecto de SOA para convertirlo en una API. En SOA, lo más importante son las necesidades del arquitecto y la adopción por parte del usuario se presupone. Por lo tanto, los arquitectos con experiencia previa en SOA enfocarán habitualmente las decisiones relativas al diseño de las API con la idea de que los usuarios de la aplicación y la interfaz tendrán las mismas necesidades y dependencias que ellos. Esto conlleva casi siempre una toma de decisiones de diseño desafortunadas. En el caso de las API, el diseño no debería centrarse en la funcionalidad, sino en la experiencia del usuario. La pregunta clave no es “¿Qué funcionalidad debo mostrar?”, sino “¿Cómo vana usar esta interfaz los desarrolladores?”. Si los desarrolladores no quieren utilizar la API, entonces no tiene ningún valor. Por lo tanto, el diseño debe centrarse en los desarrolladores y en ofrecer el menor número posible de limitaciones de acceso para la audiencia de desarrolladores objetivo.

Independientemente de que se trate de una API privada o pública, una buena experiencia de desarrollador será esencial para que logre el éxito. La experiencia de desarrollador es mucho más difícil de cuantificar que la funcionalidad mostrada. Aunque puede definirse como la suma de interacciones entre el proveedor de API y el desarrollador, el resultado de esta suma es más una sensación que una cifra: ¿cómo hace sentir a los desarrolladores la interfaz? Evidentemente, se trata de una métrica poco exacta, pero hay ciertos pasos prácticos que puede seguir en el mundo real para comprender cómo les probable que se sientan los desarrolladores con respecto a los diferentes enfoques que puede haber empleado durante el diseño de la API. En concreto, debería realizar lo siguiente: • •

11

Crear perfiles de desarrolladores Crear un prototipo y probar la API en situaciones reales

Parte 4: Diseño de una API operativa

Perfiles de desarrolladores

Creación de prototipos

No puede crear una API operativa a no ser que conozca las necesidades y las preferencias del desarrollador objetivo. Existe la tendencia a suponer que los desarrolladores que crean aplicaciones cliente con API son personas jóvenes que se describen a sí mismas como “hackers” y están obsesionadas con los protocolos y lenguajes más novedosos. Sin embargo, en muchos casos (en especial en casos de API privadas), los desarrolladores de servicios empresariales siguen siendo fieles a métodos más tradicionales de hacer las cosas.

Una vez que sepa cuáles son los objetivos de trabajo, los requisitos técnicos y las preferencias personales de los desarrolladores objetivo, podrá comenzar a crear una interfaz que tenga en cuenta esos criterios. Sin embargo, antes de crear un vínculo de producción de la API con datos reales o sistemas back-end, debería crear un prototipo ligero que se pudiera modificar de un modo más sencillo. Este prototipo le permitirá probar los supuestos de diseño que ha efectuado en función de las personas objetivo. Ilustración 4: Herramientas útiles para la creación de prototipos de API

Lo importante es que todos los proyectos de API tendrán que enfocarse a una audiencia de desarrolladores específica para lograr el éxito. En algunos casos, puede tratarse de un grupo muy homogéneo con necesidades comunes. En otros, es posible que deba hacer frente a una gama de preferencias más amplia. Independientemente de la situación, debe comprender quién va a emplear la API y cómo puede definir la interfaz para garantizar que esos desarrolladores puedan emplear los recursos back-end de un modo rápido y eficaz.

Existen diversas herramientas en línea que pueden simplificar el proceso de creación y comprobación de prototipos de API ligeros. Entre los ejemplos más conocidos se incluyen...

Por lo tanto, el primer paso es diseñar una persona (o grupo de personas) para definir el tipo o tipos de desarrolladores a los que va a dirigir las API. Esto debería incluir información relativa a lo siguiente: •

Para quién trabajan (y en qué departamento) y por qué desarrollan una aplicación

•

Conocimientos sobre programación, limitaciones técnicas y preferencias de lenguaje/protocolo

•

Carácter personal y en qué situaciones trabajan con más agrado

1 2 3

Apiary aplary.lo

RAML raml.org

SWAGGER

Una herramienta de diseño que posibilita la rápida creación de un prototipo de API sin necesidad de escribir código.

Lenguajes de descripción de API que puedan ayudar a los desarrolladores a descubrir y comenzar a utilizar la interfaz prototipo.

swagger.io

Una de las ventajas de crear un prototipo ligero basado en funciones o datos “desechables” es que le permite aplicar una seguridad básica y ofrece muy pocas limitaciones de acceso a los desarrolladores. Esto hará posible involucrar pronto a los desarrolladores objetivo, que crearán aplicaciones ligeras para probar el diseño de las API y realizarán comentarios. A continuación, podrá introducir cambios en la interfaz y volver a realizar las comprobaciones. Tras haber realizado un par de iteraciones, debería estar en el buen camino. Es evidente que nada de esto hace referencia a cómo tomar decisiones importantes y de aplicación práctica acerca del diseño de interfaces. En la parte 5, se describen las opciones de diseño de API reales. 12

Parte 5: Tipos de API La elección de un tipo de API es una de las decisiones más importantes que puede tomar un diseñador de interfaces. Las decisiones de este tipo se verán afectadas de forma inevitable por aspectos técnicos, como la naturaleza específica de los recursos back-end mostrados o las limitaciones de la organización de TI. Sin embargo, también hay que tener en cuenta otros aspectos, como los objetivos de negocio del programa de API o las necesidades y preferencias de los desarrolladores objetivo. Los tipos de diseños de API habituales pueden clasificarse del modo siguiente:

Servicio web (también denominado tunelización)

Hipermedia (también denominado “true REST”)

REST pragmática (también denominado URI)

13

Basado en eventos (también denominado IoT)

Parte 5: Tipos de API

Servicio web El tipo de diseño de servicio web es un enfoque de diseño de API basado en operaciones e independiente del transporte que emplea el lenguaje de descripción de servicios web (WDSL) para describir interfaces. Su origen se encuentra en el ámbito de la SOA, en el que se empleaban interfaces de servicio web para integrar redes de distinto tipo. Por lo tanto, puede resultar una buena elección si el programa incluye una ampliación de interfaces de SOA. La gran cantidad de herramientas disponibles para los servicios web también indica que las aplicaciones cliente a menudo se pueden construir de manera rápida y sencilla.

desarrolladores objetivo están familiarizados con estándares de SOA como WSDL, protocolo simple de acceso a objetos (SOAP) y llamada a procedimiento remoto (RPC). Para la mayoría de los desarrolladores clientes, es probable que la curva de aprendizaje resulte elevada. Esto resulta particularmente cierto en casos de API abiertas y, en especial, en aquellas centradas en dispositivos móviles. Como norma, a los desarrolladores de aplicaciones no les gusta SOAP como lenguaje de programación. Además, las herramientas disponibles para crear clientes de servicio web no suelen ser compatibles con dispositivos móviles. Aparte de las consideraciones de carácter práctico, existe un problema de percepción: el empleo del tipo de diseño de servicio web puede hacer que su organización parezca un “dinosaurio” torpe, y eso estaría relacionado con una reducción de la adopción entre desarrolladores de aplicaciones móviles.

Sin embargo, este estilo posee importantes límites en cuanto a su uso. En primer lugar, aunque el tipo independiente del transporte puede emplear el protocolo de transferencia de hipertexto (HTTP), resulta muy poco eficaz en este contexto. Por lo tanto, no es la mejor elección si los servicios se van a ampliar a la Web. Además, únicamente resulta práctico si los

REST pragmática

La transferencia de estado representacional pragmática (REST) es un tipo de diseño con un enfoque más sencillo y centrado en la Web para el diseño de interfaces de integración. Este estilo, que emplea URI en lugar de WSDL y está vinculado al transporte (únicamente admite HTTP), ha superado con creces el diseño de servicio web en el diseño de API empresariales. De hecho, el término “API web” se emplea habitualmente como sinónimo de “API RESTful” y alcanzar el estado de “RESTfulness” se considera un objetivo clave de cualquier proyecto de diseño de interfaces.

Resulta sencillo averiguar por qué el tipo de REST pragmática se ha hecho tan popular. Como el URI es intuitivo y los desarrolladores móviles y web están familiarizados sobre todo con interfaces RESTful, es probable que la adopción y la productividad por parte de los desarrolladores sea alta. Además, la concentración de HTTP hace que las API del tipo REST pragmática sean perfectas para desarrollar las aplicaciones web y móviles de hoy en día. En estos momentos, es probable que sea el tipo de diseño más buscado en la mayoría de los proyectos.

De hecho, la mayoría de las API REST que se emplean hoy en día no cumple con todos los criterios del tipo REST indicados en la definición que estableció Roy Fielding en su tesis doctoral del año 2000. Aunque REST se definió para describir formalmente el tipo de interacciones dinámicas e hipervinculadas que dirigen la Web, la mayoría de las API de la Web realiza un intercambio de datos estáticos. Por lo tanto, es más preciso hablar de este tipo de diseño como “REST pragmática”.

Sin embargo, el tipo de diseño REST pragmática no es perfecto en todos los contextos y es probable que desarrollos futuros amenacen su posición dominante. Hay un número muy determinado de compensaciones en este tipo de diseño: se limita a cuatro métodos, puede resultar “informal” y el diseño de URI no es estándar. Además, dada la expansión del Internet de las cosas (IoT) y los grandes datos, que provoca una alteración de las redes en línea, es probable que surjan retos para este enfoque tan centrado en la Web. 14

Parte 5: Tipos de API

Hipermedia El tipo de diseño de API de hipermedia es un enfoque basado en tareas cuyo objetivo consiste en ofrecer una alternativa más sostenible a la REST pragmática. Al igual que sucede con la REST pragmática, las API de hipermedia se suelen centrar en estándares URI, HTTP y RESTful. Sin embargo, en cierto modo, el tipo de diseño de hipermedia representa una aplicación más fiable de la arquitectura RESTful según Fielding, que describe por qué la Web ha demostrado ser tan escalable. Como tal, el enfoque de hipermedia está aún más centrado en la Web: los hipervínculos y formularios de la Web se reflejan en el modo en que una API de hipermedia ofrece enlaces para navegar por la introducción de

plantillas y flujos de trabajo con el objetivo de solicitar información. Al igual que la arquitectura RESTful de la Web ha demostrado ser altamente escalable y poseer una gran capacidad de evolución, una API de hipermedia bien diseñada puede seguir admitiendo aplicaciones nuevas durante años. Aunque el enfoque arquitectónico resulta se una opción muy atractiva para empresas que pretenden crear API escalables que admiten de manera fiable aplicaciones web y móviles a largo plazo, aún es un tipo de diseño emergente con una notable falta de herramientas asociadas. Esto puede influir en las tasas de adopción por parte de los desarrolladores y complicar a los desarrolladores que adopten la API la creación rápida de aplicaciones de cliente potentes.

Basado en eventos Mientras los tipos centrados en HTTP, como la REST pragmática, pueden resultar ideales para aplicaciones web y móviles tal y como las conocemos, la llegada de HTML5 e IoT está cambiando las cosas, ya que crea la posibilidad de emplear aplicaciones más dinámicas, al tiempo que requiere interfaces más ligeras. En este contexto, el tipo de diseño basado en eventos surge como alternativa independiente del transporte, lo que resulta ideal para permitir a las aplicaciones el uso de WebSocket y otras alternativas a HTTP emergentes.

resulta perfecto para el IoT y diversos casos prácticos de dispositivos móviles, en especial para mensajería instantánea, vídeo-chats, juegos para varios jugadores, etc. También es probable que resulte interesante para los desarrolladores que buscan las tecnologías más avanzadas. Por supuesto, no todos los desarrolladores están tan obsesionados con estar a la última y hay muchos casos prácticos en los que resultaría más adecuado un enfoque de RESTful convencional. HTTP sigue siendo el protocolo de transporte que dirige la Web y no se adapta demasiado bien a los eventos enviados por clientes. Además, el modelo de solicitud-respuesta en el que se basa este tipo de diseño hace que la construcción de aplicaciones de clientes resulte más compleja para los desarrolladores.

Este estilo, que se centra en eventos iniciados por el servidor o el cliente, ofrece una opción que supone un gasto reducido y que es capaz de ofrecer un rendimiento mejor en casos en los que se transmite una gran cantidad de mensajes breves entre el back-end y la aplicación. Por lo tanto,

15

Parte 5: Tipos de API

Ilustración 5: Tipos de arquitecturas para el diseño de API

Servicio web

REST pragmática

Hipermedia

Basado en eventos

Relacionado con SOA Múltiples herramientas disponibles No adecuado para móviles

Ideal para aplicaciones web y móviles Familiar para la mayoría de los dispositivos de aplicaciones Puede no resultar adaptable a lo largo del tiempo

Muy centrado en la Web Escalable y con capacidad de evolución Desconocido para muchos dispositivos

Adecuado para IoT y dispositivos Ligero y dinámico No adecuado para escenarios estándar

El tipo que seleccione dependerá de las limitaciones técnicas, los objetivos de negocio y las preferencias del desarrollador. Procure no caer en la trampa de adoptar un tipo “que esté de moda” si no es el adecuado para su contexto específico. Al mismo tiempo, procure escoger un tipo de diseño que vaya a demostrar su escalabilidad y adaptabilidad a largo plazo, ya que los recursos cambian, la audiencia de usuarios aumenta y la propia naturaleza de las conexiones de red en línea evoluciona. Independientemente del tipo de diseño que elija, hay ciertos componentes arquitectónicos que deseará incluir en su API. En la parte 6, destacaremos dichos componentes y explicaremos cómo se organizarán.

16

Parte 6: Arquitectura de API Los tipos de diseño de la arquitectura mencionados anteriormente deberán ofrecerle un modelo de cómo diseñar el marco de trabajo arquitectónico que permite la funcionalidad exclusiva de la implementación de la API. Algunos casos prácticos requerirán la implementación de tipos de diseño específicos. No obstante, también es importante tener en cuenta que existe un cierto número de componentes que deberían incluirse en cualquier arquitectura de API, independientemente del caso práctico.

Ilustración 6: Capas arquitectónicas

Aplicaciones de cliente

Estos componentes de la arquitectura comunes no se deberán integrar en la implementación de ninguna API. En lugar de ello, se deberán implementar en una estructura de API central que se encuentre entre las API de la organización y las aplicaciones del cliente que hacen uso de esas API. Al señalar estos componentes, resulta más rápido y sencillo diseñar API adicionales para actualizar una determinada gama de API a la vez, así como para garantizar una ejecución fluida de las API, los sistemas back-end y las aplicaciones de cliente.

Capa de seguridad

Usuarios finales

Capa de caché

Capa de representación

Para lograr una eficacia máxima, estos componentes deberán diseñarse por capas, de manera que todo el tráfico de datos deba pasar por cada una de las capas indicadas a la derecha y en el orden especificado.

Capa de articulación

17

Sistemas back-end

Implementación de API

Parte 6: Arquitectura de API

Capa de seguridad

Capa de representación

Las API son capaces de desvelar todo un mundo de oportunidades empresariales. Además de eso, también son capaces de plantear a la empresa graves y nuevas amenazas a la seguridad, ya que exponen ante el mundo exterior sistemas back-end y datos con información confidencial. Las API son vulnerables a muchas de las amenazas a la seguridad más comunes de Internet, además de una gama de amenazas nuevas específicas de las API. Por lo tanto, resulta esencial implementar una seguridad sólida específica para las API como parte principal de la arquitectura de API.

Es evidente que la representación de la API debe ser lo más sencilla posible. Al extraer este elemento de la implementación, podrá centrarse en la creación centralizada de un método de bienvenida para las API que no suponga un impacto para las propias API o los recursos back-end. De este modo, resulta mucho más fácil presentar sistemas back-end complejos como interfaces centradas en la Web o en móviles que los desarrolladores puedan comprender y aprovechar rápidamente para crear aplicaciones potentes y sencillas.

Esta necesidad de seguridad sólida puede entrar en conflicto con un objetivo básico del diseño de API: una API bien diseñada facilita a los desarrolladores la creación de aplicaciones que ofrecen un acceso sin problemas a los recursos empresariales. Es probable que una seguridad sólida afecte a esta facilidad de acceso. La implementación de seguridad en una arquitectura de API centralizada (en lugar de en la implementación de las API) ayudará a mitigar este impacto, al igual que lo hará la posibilidad de usar tecnologías de gestión flexible del acceso como OAuth y OpenID Connect.

Capa de articulación Aunque algunas aplicaciones pueden ofrecer valor mediante el acceso a un único recurso a través de una única API, las posibilidades aumentan exponencialmente si se combinan datos de múltiples API (incluidas las de otras empresas) y recursos back-end. La implementación de una capa de articulación junto a las propias interfaces puede permitir estas combinaciones, así como simplificar el proceso de composición de implementaciones nuevas a partir de múltiples recursos back-end.

Capa de caché

El modo más eficiente de crear una arquitectura de API centralizada es la implementación de una solución de gestión de API. En la parte 7, se destacan los componentes clave de la gestión de API.

La eficiencia de la interfaz resultará esencial para ofrecer una experiencia fluida para desarrolladores y usuarios finales, algo que necesitarán para cumplir los objetivos de adopción y retención del programa de API. Una forma de maximizar la eficiencia de las API es colocar una capa de caché junto al nivel exterior de la arquitectura de API. Esta capa debería permitir que se envíen respuestas de caché en caso de solicitudes comunes para reducir la presión que soportan las implementaciones de API y los recursos back-end.

18

Parte 7: Gestión de API La creación de una infraestructura que centralice los componentes arquitectónicos habituales de API seguras y centradas en los desarrolladores puede simplificar en gran medida el proceso de implementación de API que agregan un valor real a su negocio. No obstante, la creación de dicha infraestructura de forma interna puede suponer un reto considerable. Por suerte, ahora hay diversos proveedores de software para empresas que ofrecen soluciones de “gestión de API” que evitan tener que desarrollar esta infraestructura esencial de forma interna.

Es más, tal y como indica su nombre, las soluciones de gestión de API también incluyen funciones para la gestión y la optimización del rendimiento de API a largo plazo. Además, las soluciones más potentes también presentan funciones para la creación de una interfaz basada en la Web a través de la que los desarrolladores puedan descubrir, acceder e informarse acerca de las API, algo que supone una parte esencial de la presentación de una API centrada en los desarrolladores y que no se puede integrar en la implementación.

19

Parte 7: Gestión de API

Componentes de la gestión de API Una solución de gestión de API de nivel empresarial tendrá dos componentes clave: • •

Puerta de enlace de API: ofrece las funciones de seguridad, memoria caché y articulación necesarias para implementar una arquitectura de API principal. Portal de desarrolladores: ofrece una interfaz personalizable a través de la que los desarrolladores pueden acceder a las API, así como documentación, foros comunitarios y otro contenido útil. Ilustración 7: Componentes de la gestión de API

Usuario final

Desarrollador de aplicaciones

Portal de desarrolladores

Propietario de API

Arquitecto de API

Aplicación de cliente

Puerta de enlace de API

Implementación de API

Sistemas back-end

Conviene tener en cuenta que la gestión de API no es un mero requisito técnico. Desempeñará un papel inevitable en el éxito empresarial del programa de API de cualquier empresa. La gestión de la composición, el rendimiento y la seguridad de las API empresariales es vital para garantizar que la organización obtenga una buena rentabilidad de su inversión en un programa de API. Del mismo modo, resulta esencial involucrar y gestionar de forma activa a los desarrolladores para garantizar que creen aplicaciones que ofrezcan un valor de negocio. Para la mayoría de las empresas, una estructura de gestión de API resultará esencial para el diseño, la implementación y el mantenimiento de API que emplearán los desarrolladores para crear aplicaciones nuevas realmente potentes. Descubra los aspectos esenciales de la gestión de API mediante el libro electrónico sobre los cinco pilares de la gestión de API 20

Conclusión Desde un punto de vista arquitectónico, las API representan una ampliación de la SOA. Igual que la SOA ha creado interfaces para abrir sistemas heredados para su reutilización en servicios nuevos que podrían ampliar los límites organizativos, las API se emplean para abrir el back-end empresarial para que los desarrolladores creen aplicaciones para dispositivos móviles y la Web pública. Se trata de una ampliación importante y los requisitos de diseño de una API para la Web seguramente sean muy distintos de los de un servicio web de SOA.

Los arquitectos y los propietarios de API deben comunicarse para asegurarse una visión común de los objetivos clave, el modo en que desean alcanzarlos y cómo calcularán su éxito. Para asegurarse de que la comunicación es eficaz, debe existir un gurú de API que pueda rellenar las lagunas existentes entre los roles técnicos y empresariales. Dicho gurú deberá analizar las necesidades de los líderes empresariales, los propietarios de API, los desarrolladores de aplicaciones y los arquitectos empresariales para negociar un conjunto adecuado de objetivos, tareas y métricas.

Mientras que los programas de SOA suelen basarse en la necesidad de reducir los costes de TI, los programas de API se centran en la generación de nuevos flujos de ingresos. Una API nueva conecta diversos activos empresariales existentes para crear valor de un modo que antes no se había previsto. Un buen diseño de API siempre se centra en los resultados de negocio. Por lo tanto, el diseño de API y las prácticas arquitectónicas relacionadas deben alinearse con la estrategia de negocio de la organización desde el inicio del proceso.

En la práctica, el diseño de una API para lograr el éxito del negocio suele suponer la creación de una interfaz que los desarrolladores realmente quieran emplear. Por lo tanto, antes de crear nada, es esencial realizar una investigación sistemática de la audiencia de desarrolladores para comprender quiénes son los desarrolladores objetivo y qué es lo que desean obtener de una API. También puede resultar útil comprobar las suposiciones relacionadas con las preferencias de los desarrolladores mediante el lanzamiento de prototipos de API ligeros.

21

Conclusión

Una vez que esté listo para diseñar la implementación de API, tendrá que elegir el tipo de diseño que mejor se adapte al proyecto. Las API de servicio web servirán para programas internos destinados a desarrolladores con experiencia en SOA. Las API de tipo REST pragmática son más adecuadas para proyectos de API abiertas centradas en dispositivos móviles y la Web. Los tipos de diseño de hipermedia y basados en eventos surgen como enfoques que podrían resultar más sostenibles en un futuro basado en dispositivos móviles e IoT.

La manera más eficiente y eficaz de implementar una arquitectura de API central (y garantizar así que el programa de API siga ofreciendo éxitos a largo plazo) es adoptar una solución de gestión de API. Existen diversas soluciones en el mercado, pero la mayoría incluye dos componentes comunes: • •

Independientemente del tipo de diseño, existen determinados elementos arquitectónicos que deben poseer todas las API: seguridad, caché, representación y articulación. Para lograr una eficiencia y una gestionabilidad máximas, estos elementos no se deberán integrar en las implementaciones de API individuales. En lugar de ello, todas las API deberán emplear una arquitectura de API central estructurada en capas que se encuentre entre el nivel exterior de la empresa y las propias API.

Una puerta de enlace de API que ofrece funciones de seguridad y otra infraestructura clave Un portal de desarrolladores que simplifica el proceso de involucración y habilitación de desarrolladores

Hay mucho en juego en los proyectos de API empresariales actuales: grandes oportunidades de negocio, importantes riesgos de seguridad, etc. Resulta esencial prepararse antes de comenzar a crear una API: alinear los objetivos de diseño y los objetivos de negocio; establecer las preferencias de los desarrolladores objetivo; seleccionar un tipo de implementación adecuado; e implementar una estructura de gestión de API. Después de ello, estará listo para crear una API realmente valiosa.

Ilustración 8: Requisitos previos para un diseño adecuado Alineación de objetivos técnicos y empresariales

Selección de un tipo de diseño de API

Establecimiento de preferencias de desarrolladores

Implementación de una infraestructura de API

€ CA API Management es el único que permite a las organizaciones integrar sistemas, simplificar la implementación de aplicaciones y monetizar datos con los niveles de protección y seguridad de API que necesitan las empresas en la actualidad. Obtenga información sobre CA API Management en ca.com/es/api. 22

Acerca de CA API Management Con más de 300 clientes de gestión de API en sectores tan diversos como el de las comunicaciones, los servicios financieros, los organismos gubernamentales y la venta minorista, CA Technologies ofrece la mejor tecnología y conocimientos del sector para ayudar a las organizaciones a ofrecer API con un gran valor. CA ofrece una solución de gestión de API completa que incluye una puerta de enlace de API con total funcionalidad que posee funciones de seguridad de nivel militar, además de un portal de desarrolladores que se proporciona en versión in situ y SaaS. Obtenga información sobre CA API Management en ca.com/es/api.

API Academy Servicios de estrategia, arquitectura y diseño de API El equipo de API Academy está formado por expertos del sector que se han unido gracias a CA Technologies para desarrollar recursos gratuitos para la comunidad y ofrecer servicios de asesoría expertos para organizaciones que deseen mejorar sus programas de API. Para descubrir cómo API Academy puede ayudar a su organización con la estrategia, la arquitectura y el diseño de API, visite apiacademy.com.

CA Technologies (NASDAQ: CA) crea software que impulsa la transformación de las empresas y les permite aprovechar las oportunidades de la economía de las aplicaciones. El software se encuentra en el corazón de cada empresa, sea cual sea su sector. Desde la planificación hasta la gestión y la seguridad, pasando por el desarrollo, CA trabaja con empresas de todo el mundo para cambiar la forma en que vivimos, realizamos transacciones y nos comunicamos, ya sea a través de la nube pública, la nube privada, plataformas móviles, entornos de mainframe o entornos distribuidos. Obtenga más información en ca.com/es. Copyright © 2015 CA. Todos los derechos reservados. Todas las marcas, nombres comerciales, logotipos y marcas de servicio a los que se hace referencia en este documento pertenecen a sus respectivas empresas. El propósito de este documento es meramente informativo. CA no se hace responsable de la exactitud o totalidad de esta información. En la medida de lo permitido por la ley vigente, CA proporciona esta documentación “tal cual”, sin garantía de ningún tipo, incluidas, a título enunciativo y no taxativo, las garantías implícitas de comerciabilidad, adecuación a un fin específico o no incumplimiento. CA no responderá en ningún caso de las pérdidas o daños, directos o indirectos, que se deriven del uso de esta documentación, incluidas, a título enunciativo y no taxativo, la pérdida de beneficios, la interrupción de la actividad empresarial, la pérdida del fondo de comercio o la fuga de datos, incluso cuando CA hubiera podido ser advertida con antelación y expresamente de la posibilidad de dichos daños. CS200-131275