Arquitectura y estrategia de API Un enfoque coordinado

22

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.

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.

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.

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.

Introducción

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:

3

Parte 1: De SOA a API

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

Objetivo de integración

Elemento impulsor del proyecto

Consumidor de la interfaz

Interna o para partners

Costes de TI

Arquitectos empresariales

Externa, a menudo para clientes

Ingresos para el negocio

Desarrolladores de aplicaciones

SOA API

$$$

• 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.

• 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.

4

Objetivos del diseño de API

Parte 1: De SOA a 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.

Parte 2: La cadena de valor de las API

5

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.

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

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.

Ilustración 2: La cadena de valor de las API

Sistemas back-end Proveedores de API Desarrolladores de aplicaciones

Aplicaciones de cliente Usuarios finales

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 directaUna 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

7

• ¿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?

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.

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.

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.

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.

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.

Toma de decisiones sobre el diseñoLa 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:

Parte 2: La cadena de valor de las API

8

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

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

9

Ilustración 3: Alineación de objetivos de API

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.

Gurú de APIGestor de programas API Arquitecto de API

Objetivos Tareas Métricas

Desarrolladores objetivoLíderes empresariales

Recursos técnicosOportunidades de ingresos

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

Asignación de un patrocinadorPara 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

10

Notas sobre la estrategia de negocio de las APILos 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.

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

Parte 4: Diseño de una API operativaDesde 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:

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

11

12

Perfiles de desarrolladoresNo 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.

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.

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

Creación de prototipos 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.

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.

Parte 4: Diseño de una API operativa

Ilustración 4: Herramientas útiles para la creación de prototipos de API

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...

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

Apiaryaplary.lo

RAMLraml.org

SWAGGERswagger.io

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

123

13

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:

Parte 5: Tipos de API

Servicio web (también

denominado tunelización)

REST pragmática (también

denominado URI)

Hipermedia (también

denominado “true REST”)

Basado en eventos (también

denominado IoT)

14

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.

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

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.

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.

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”.

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.

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.

REST pragmática

Servicio web

Parte 5: Tipos de API

151515

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.

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.

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,

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.

Basado en eventos

Hipermedia

Parte 5: Tipos de API

16

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.

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

Parte 5: Tipos de API

17

Ilustración 6: Capas arquitectónicas

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.

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.

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.

Parte 6: Arquitectura de API

Capa de seguridad

Capa de caché

Capa de representación

Capa de articulación

Aplicaciones de cliente

Usuarios finales

Sistemas back-end

Implementación de API

Capa de seguridadLas 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.

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 caché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.

Capa de representaciónEs 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.

Capa de articulaciónAunque 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.

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.

18

Parte 6: Arquitectura 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.

Parte 7: Gestión de API

19

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.

20

Ilustración 7: Componentes de la gestión de API

Desarrollador de aplicaciones

Aplicación de clienteUsuario final

Propietario de API

Implementación de API

Portal de desarrolladores

Puerta de enlace de API

Parte 7: Gestión de API

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

Arquitecto de API

Sistemas back-end

Componentes de la gestión de APIUna 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.

2121

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.

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.

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.

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.

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.

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.

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:

• 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.

22

Ilustración 8: Requisitos previos para un diseño adecuado

Alineación de objetivos técnicos y empresariales

Establecimiento de preferencias de desarrolladores

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

Implementación de una infraestructura de API

Conclusión

€

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.

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

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.

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 APIEl 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.