Tipos de API y cómo decidir cuál desarrollar

Las interfaces de programación de aplicaciones, normalmente conocidas como API, liberan el potencial de los datos y permiten a las empresas conectar sistemas, aplicaciones, dispositivos y conjuntos de datos. Para entender qué tipo de API es el más adecuado para un proyecto, es importante tener en cuenta varios factores: el uso que se le va a dar, qué usuarios accederán a la API y la utilizarán, y los sistemas y conjuntos de datos que habrá que conectar. Para conseguir que el rendimiento y la gestión de las API sean eficaces, es vital determinar el tipo de API óptimo y diseñar y desarrollar su arquitectura de acuerdo con ello.

No es habitual que una organización decida que necesita una API de la nada; muy a menudo, empiezan con una idea, aplicación, innovación o caso de uso que requiere conectarse a otros sistemas o conjuntos de datos.

Las API entran en juego como un medio de conexión entre los sistemas y los conjuntos de datos que deben integrarse.

Las organizaciones pueden utilizar diferentes API para una amplia variedad de propósitos, desde exponer internamente una funcionalidad del sistema central hasta habilitar una aplicación móvil para los clientes. El enfoque de conectividad API-led de MuleSoft engloba tres categorías de APIs:

• APIs de sistemas: las API de sistemas desbloquean datos de los sistemas centrales de registro dentro de una organización. Los sistemas ERP, de clientes y de facturación, así como las bases de datos privadas, son ejemplos de sistemas clave en los que las API pueden desbloquear datos.
• APIs de procesos: las API de procesos interactúan con los datos y los compilan en un solo sistema o a través de varios, acabando así con los silos. Este tipo de API permite combinar datos y coordinar varias API de sistemas para fines empresariales específicos. Un ejemplo de este proceso es la creación de una vista completa de los clientes, el despacho de pedidos y el estado de los envíos.
• APIs de experiencias: las API de experiencias proporcionan contexto empresarial para los datos y procesos desbloqueados y establecidos con APIs de sistemas y procesos. Las API de experiencias exponen los datos para que pueda utilizarlos la audiencia de destino, como en aplicaciones móviles, portales internos para datos de clientes, etc.

Una vez que se ha determinado el caso de uso para las API de una organización, es el momento de determinar qué usuarios podrán acceder a ellas. A menudo, el caso de uso y el usuario deseado van de la mano: por ejemplo, cuando se busca facilitar datos de clientes a los agentes internos de ventas y servicios, la audiencia de destino serán los empleados de la propia empresa.

A continuación se analizan tres tipos de APIs en función de su gestión y los usuarios que acceden a ellas:

External APIs can be accessed by third-parties (developers, partners, etc.) that are external to the organization. They often make an organization's data and services easily accessible on a self-service basis by developers around the world who are looking to create innovative applications and integrations.  An example of an open API is the Google Maps API that is used across third-party applications (such as ridesharing and food delivery apps) to enable location tracking and mapping.

Internal APIs are the opposite of open APIs in that they are inaccessible to external consumers and only available to an organization’s internal developers. Internal APIs can enable enterprise-wide initiatives from the adoption of DevOps and microservice architectures to legacy modernization and digital transformation. The use and reuse of these APIs can enhance an organization's productivity, efficiency, and agility. An example of a reusable internal API is if a call center team created a customer information API used in a call center application to access their name, contact information, account info, etc. That team can then reuse this same API in a customer-facing web application or mobile application.

Las API de partners son un término medio entre las internas y las externas. Ello se debe a que son accesibles a personas ajenas a la organización, pero solo para aquellas que tienen permisos exclusivos. Normalmente, este acceso especial se concede a determinados terceros para facilitar una colaboración empresarial estratégica.

Un caso de uso común de las API de partners se produce cuando dos organizaciones desean compartir datos, como por ejemplo, el departamento sanitario de una provincia y un hospital de su jurisdicción. La API de partners se configuraría de forma que cada organización pueda tener acceso a los datos necesarios si cuenta con las debidas credenciales y permisos.

Otro factor a tener en cuenta a la hora de elegir una API es el estilo o estilos de arquitectura que se van a emplear. Es esencial escoger el estilo o patrón de arquitectura que mejor se ajuste al caso de uso deseado para la API si se necesitan ciertas capacidades funcionales. Este tipo de decisiones de diseño de las API suelen tomarlas equipos de corte más técnico.

Antes de tomar esta decisión, hay que tener una comprensión básica de la infraestructura existente, es decir, saber si los sistemas están alojados localmente o en la nube, qué sistemas y conjuntos de datos son necesarios, qué protocolos de seguridad deben implantarse y qué funcionalidades se requieren. De acuerdo con la filosofía de diseño API-first, la funcionalidad y las experiencias de usuario que se buscan son lo que debería guiar los cambios que se efectúen en los activos de TI heredados, en lugar de ser estos activos quienes dicten la funcionalidad o la experiencia.

Existen varios estilos de arquitectura para APIs, así como diferentes formatos de datos incluidos en estos estilos; a continuación se presentan los más comunes:

• REST: REST (estado de transferencia representacional) es un estilo de arquitectura que separa las necesidades del usuario de API de las del proveedor gracias a comandos que se integran en el protocolo de red subyacente. Los clientes utilizan los enlaces y formularios incluidos para realizar acciones (p. ej., leer, actualizar, compartir, aprobar, etc.). HTML es el ejemplo más conocido de este estilo, y hay muchos otros formatos exclusivos para APIs (HAL, CollectionJSON, Siren, etc.). Son muchas las ventajas de las API de REST, como la flexibilidad y la compatibilidad con formatos de datos populares como JSON y XML, entre otros.
• RPC: las llamadas a procedimientos remotos, o RPC, normalmente requieren que los desarrolladores ejecuten bloques específicos de código en otro sistema. La invocación remota de tipo RPC de los procedimientos de otros sistemas normalmente exige que los desarrolladores realicen llamadas a dichos procedimientos por su nombre. Las llamadas RPC son independientes del protocolo, por lo que son potencialmente compatibles con muchos protocolos, aunque no incluyen las ventajas de usar funciones nativas de protocolo (p. ej., el almacenamiento en caché). La proliferación de nombres de procedimiento no estandardizados entre una API de RPC y otra hace que el vínculo entre los usuarios y los proveedores de una API sea más exclusivo, lo cual impone una sobrecarga de trabajo a los desarrolladores que tienen que cuidar de todos los aspectos de un ecosistema de APIs mediado por RPC. La arquitectura de tipo RPC se puede observar en tecnologías de API tan conocidas como SOAP, GraphQL y gRPC.
• Basadas en eventos/streaming: las API basadas en eventos, a menudo conocidas como arquitecturas de eventos, de tiempo real, de streaming, asíncronas o push, no esperan a que el usuario de API realice la llamada para mandar una respuesta. La respuesta se emite en cuanto se produce un evento. Estos servicios muestran eventos a los que se pueden suscribir los clientes para recibir actualizaciones siempre que hay cambios en los valores establecidos del servicio. Entre las variantes de este estilo se encuentran los enfoques reactivos, de publicación/suscripción, de notificación de eventos, y CQRS.

Vivimos rodeados de todo tipo de eventos para los que este modelo de API funciona bien. Estos son tan solo algunos:

• Cuando una cuenta de Twitter publica un nuevo tuit.
• Cuando la temperatura de un termómetro remoto cambia.
• Cuando un vehículo pasa por un sensor en un pavimento.
• Cuando una cámara de seguridad detecta movimiento en su campo de visión.
• Cuando un electrocardiógrafo detecta un pulso irregular.
• Cuando se abre una salida de emergencia.
• Cuando se activa un detector de humo.

Diseñar y gestionar APIs eficaces requiere tener en cuenta muchos aspectos. El contenido anterior presenta una panorámica de las diferentes decisiones que debe tomar una organización a la hora de preparar el diseño, la implantación y la gestión de una API. Para obtener más información, puedes descargar nuestro whitepaper sobre conectividad API-led.