Añadir la web de API web

Objetivos de aprendizaje

Después de completar esta unidad, podrá:

• Explicar dos razones por las que las aplicaciones web se están haciendo más populares.
• Exponer los usos comunes de las API web.
• Comprender la economía de API y el motivo por el que el crecimiento de las API ha sido tan importante.

Las API compatibles con la red cambian el juego

Las API no están limitadas a lo que puede encontrarse en la misma red local. Los desarrolladores y los integradores independientes también pueden consumir las API ofrecidas por sistemas y dispositivos remotos. Estas pueden ser conexiones privadas, como las redes encontradas en empresas con varias ubicaciones y centros de datos, o una red pública como Internet. Las claves para esta extensa red son los extremos de API.

Piense en extremos como tomas eléctricas a las que se conectan dispositivos de consumo.

El número y los tipos de dispositivos que pueden conectarse a los enchufes eléctricos están limitados por la imaginación de los inventores y la capacidad de utilidad. De la misma manera, el número de aplicaciones que pueden utilizar los datos abstraídos por un extremo de API está limitado por la imaginación de los desarrolladores y la capacidad de la infraestructura de los proveedores de API.

Buen ejemplo: Un poco después de que Google ofreciera una API para Google Maps, miles de desarrolladores de terceros presentaron aplicaciones exclusivas e innovadoras que consumían esta API, incorporando así la funcionalidad de creación de mapas de Google directamente en sus aplicaciones. Piense en Yelp, Lyft, Tesla y cualquier otea aplicación que proporcione un mapa con los derechos de autor de Google en la esquina.

Por esta razón, nos solemos referir a las API como un motor de innovación, especialmente para los Trailblazers de integración que se fijan en la gran cantidad de API disponibles como si fueran terceros con los que crear nuevos resultados empresariales y experiencias de clientes.

Economía de API

Dependiendo del volumen de llamadas o de alguna otra manera de desglosar diferentes niveles de servicio, es posible que un proveedor como Google le cobre al desarrollador de la aplicación un cargo por utilizar la API. Así es como se origina la idea de una economía de API.

Ahora, el desarrollador de la aplicación debe sopesar todos los costes de utilizar una API en comparación con desarrollar la funcionalidad desde cero. O bien, como suele ocurrir en la economía de API, el desarrollador puede buscar a un proveedor más económico para obtener un servicio similar. Google Maps, por ejemplo, tiene varios competidores muy conocidos, entre los que se encuentra Here.com.

El aumento de la economía de API está impulsado por los proveedores de servicio que compiten para abordar esta necesidad de mayor productividad y datos comunes del desarrollador. Para cada uno de los varios tipos de funcionalidades que se pueden invocar mediante las API (como el procesamiento de una tarjeta de crédito, la creación de mapas, la navegación y la traducción), normalmente hay varios proveedores de API que compiten por captar la atención de desarrolladores de aplicaciones e integradores independientes. A su vez, a medida que se proporcionan más funciones en forma de servicios basados en API, la economía de API acelera la tendencia hacia un mundo de aplicaciones que están compuestas principalmente por API existentes. Cuanto más componible sea la solución final, más flexibilidad existirá a la hora de incorporar nuevas funciones de otras API que suban el nivel en cuanto a la capacidad general de la empresa.

Crecimiento de las API antes y ahora

Es posible que piense que las API compatibles con la red son el mayor descubrimiento hasta la fecha. Es posible que también se pregunte lo siguiente: si son tan geniales, ¿por qué la industria tecnológica no las ha descubierto antes? Pues resulta que sí que lo hizo.

En los tiempos en los que Unix se lanzó al mercado, era común que los programadores invocaran lógica empresarial de manera remota desde otra máquina en una red mediante una tecnología llamada RPC, o llamada de procedimientos remotos.

¿Está preparado para un buen tazón de acrónimos? Con el tiempo, las RPC cedieron el paso a otras formas de solicitudes de funciones y de datos remotos, como el DDE (intercambio de datos dinámicos) de red, CORBA (common object request broker architecture), EDI (intercambio electrónico de datos), etc. Con el tiempo, surgió algo llamado XML-RPC (¡toma ya! RPC de nuevo). Más tarde, evolucionó a lo que actualmente conocemos como servicios de web, basados en XML y en el protocolo de acceso acceso a objetos simples (SOAP).

Cada vez que surgía una nueva tecnología para acceso remoto de datos o funcionalidades, la industria pensaba que, finalmente, habíamos conseguido la utopía. Pero luego llegaron las API web que están de moda hoy en día, aquellas que, como ya hemos dicho antes, se basan en la funcionalidad integrada en el protocolo web (HTTP) mediante el uso de verbos especiales como GET, PUT y POST. Sí, se trata del mismo protocolo de web que usted utiliza todos los días para visitar sus sitios web favoritos.

El (posible) futuro de la integración

Si la historia es un indicador del futuro, es posible que la manera en la que integramos entre sistemas sea debido a un cambio. Ahora existen dos tecnologías prácticamente nuevas similares a las API a medio camino del enfoque web actual, que se ha convertido en el favorito. Una es GraphQL, que viene de Facebook, y la otra gRPC, que viene de Google.

Ambas tienen sus propias ventajas en cuanto a las API de web actuales. Por ejemplo, GraphQL está inspirada en la idea de un gráfico social y la manera en la que diferentes elementos de datos como amigos, fotografías, lugares de trabajo, etc. forman laberintos de información relacionada. GraphQL hace que se pueda solicitar información de un gráfico de datos completo de una vez (en comparación con los varios recorridos de solicitudes que tienen que ejecutar las API tradicionales con el mismo fin).

Por otra parte, gRPC tiene sus propias ventajas. Se basa en HTTP/2 (HTTP versión 2), que puede transmitir datos de manera bidireccional. Utilizando HTTP/2, gRPC puede convertir una API en una API de transmisión que proporcione sus datos a la aplicación de consumo tan pronto como esos datos estén disponibles. Para algunas aplicaciones en tiempo real, como un teletipo de bolsa, es una manera mucho más eficaz de obtener datos en lugar de forzar a la aplicación para que compruebe constantemente si hay nuevos datos disponibles como lo hacen las API tradicionales.

Misma idea, tecnología diferente

Independientemente de cuál sea el protocolo web, GrapghQL, gRPC o cualquier enfoque de API que esté todavía por descubrir, al final, la idea de las API conectables en red se basa en convertir la capacidad de una empresa en un servicio conectable en red que otras aplicaciones puedan tratar de manera remota como una parte externa de su propia experiencia de cliente. A medida que crece el inventario de partes externalizables (la economía de API), también crece la oportunidad de superar a la competencia con innovaciones y experiencias que serían difíciles de conseguir con un sistema totalmente interno.

La oportunidad también funciona a la inversa. ¿Qué competencias empresariales debería ofrecer su organización tanto a nivel interno como a desarrolladores externos a nivel de servicio conectable en red en forma de API? Es la pregunta del millón, sobre todo para aquellas empresas que quieren convertirse en Trailblazers de integración.