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.
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.
2
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.
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 Ilustración 1: SOA en comparación con las API
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 SOA API
aplicaciones basadas en móviles y la Web, y a menudo
están en contacto directo con el cliente.
Objetivo de Externa, a menudo para
Interna o para partners
• Los programas SOA suelen surgir en los departamentos de TI integración clientes
y se centran en el ahorro de costes, pero los programas API
Elemento impulsor
suelen diseñarse en organizaciones de desarrollo empresarial $$$ del proyecto
Costes de TI Ingresos para el negocio
y se centran en la generación de ingresos nuevos.
• La mayoría de los programas SOA los crean arquitectos Consumidor de la Desarrolladores de
Arquitectos empresariales
empresariales para arquitectos empresariales con el objetivo interfaz aplicaciones
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
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.
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 Aplicaciones de cliente Usuarios finales

de aplicaciones

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

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 Desarrolladores objetivo

Gestor de programas API Gurú de API Arquitecto de API

Oportunidades de ingresos 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.
11
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
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.
Lo importante es que todos los proyectos de API tendrán que enfocarse a una
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

1
audiencia de desarrolladores específica para lograr el éxito. En algunos casos, Apiary Una herramienta de diseño que
posibilita la rápida creación de un
puede tratarse de un grupo muy homogéneo con necesidades comunes. aplary.lo
prototipo de API sin necesidad de
En otros, es posible que deba hacer frente a una gama de preferencias más Existen diversas
escribir código.

amplia. Independientemente de la situación, debe comprender quién va herramientas en línea

2
que pueden simplificar
a emplear la API y cómo puede definir la interfaz para garantizar que esos el proceso de creación
y comprobación
desarrolladores puedan emplear los recursos back-end de un modo de prototipos de
API ligeros.
rápido y eficaz.
RAML
Lenguajes de descripción de
raml.org
API que puedan ayudar a los
desarrolladores a descubrir

3
Entre los ejemplos más y comenzar a utilizar la
conocidos se incluyen... interfaz prototipo.
Por lo tanto, el primer paso es diseñar una persona (o grupo de personas) SWAGGER
para definir el tipo o tipos de desarrolladores a los que va a dirigir las API. swagger.io

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

REST pragmática Basado en eventos
(también (también
(también (también
denominado denominado
denominado URI) denominado IoT)
tunelización) “true REST”)

13
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.
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.
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”.
14
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.
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.
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
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.
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
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.
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.
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 Adecuado para IoT y dispositivos
Escalable y con capacidad Ligero y dinámico
de evolución No adecuado para escenarios estándar
Desconocido para muchos
dispositivos

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 Ilustración 6: Capas arquitectónicas
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
Aplicaciones
incluirse en cualquier arquitectura de API, independientemente de cliente
Capa de seguridad
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 Usuarios
se encuentre entre las API de la organización y las aplicaciones finales Capa de caché
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 Sistemas
representación back-end
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.
Implementación
Capa de articulación
de API

17
Parte 6: Arquitectura de API
Capa de seguridad
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.
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.
18
Capa de representación
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.
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.
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.
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.
19
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

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

Desarrollador de
aplicaciones
Portal de desarrolladores Propietario de API Arquitecto de API

Usuario final 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.
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.
21
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 La manera más eficiente y eficaz de implementar una arquitectura de API
elegir el tipo de diseño que mejor se adapte al proyecto. Las API de servicio central (y garantizar así que el programa de API siga ofreciendo éxitos a largo
web servirán para programas internos destinados a desarrolladores con plazo) es adoptar una solución de gestión de API. Existen diversas soluciones
experiencia en SOA. Las API de tipo REST pragmática son más adecuadas en el mercado, pero la mayoría incluye dos componentes comunes:
para proyectos de API abiertas centradas en dispositivos móviles y la Web.
• Una puerta de enlace de API que ofrece funciones de seguridad y otra
Los tipos de diseño de hipermedia y basados en eventos surgen como
infraestructura clave
enfoques que podrían resultar más sostenibles en un futuro basado en
• Un portal de desarrolladores que simplifica el proceso de involucración
dispositivos móviles e IoT.
y habilitación de desarrolladores
Independientemente del tipo de diseño, existen determinados elementos
Hay mucho en juego en los proyectos de API empresariales actuales:
arquitectónicos que deben poseer todas las API: seguridad, caché,
grandes oportunidades de negocio, importantes riesgos de seguridad, etc.
representación y articulación. Para lograr una eficiencia y una gestionabilidad
Resulta esencial prepararse antes de comenzar a crear una API: alinear los
máximas, estos elementos no se deberán integrar en las implementaciones
objetivos de diseño y los objetivos de negocio; establecer las preferencias
de API individuales. En lugar de ello, todas las API deberán emplear una
de los desarrolladores objetivo; seleccionar un tipo de implementación
arquitectura de API central estructurada en capas que se encuentre entre
adecuado; e implementar una estructura de gestión de API. Después de ello,
el nivel exterior de la empresa y las propias API.
estará listo para crear una API realmente valiosa.

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

Alineación de objetivos técnicos Establecimiento de preferencias Selección de un tipo Implementación de una

y empresariales de desarrolladores de diseño de API 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