Poner la web en 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.
  
• Establecer usos comunes de API de web.
  
• Comprender la economía de API y por qué el crecimiento de API fue significativo.
  

Las API conectables en red han cambiado las reglas del juego

Las API no están limitadas a lo que se puede encontrar en la misma red local. Los desarrolladores e integradores ciudadanos también puede consumir las API ofrecidas por dispositivos y sistemas remotos. Estas pueden ser conexiones privadas, como las redes de compañías con múltiples ubicaciones y centros de datos, o pueden ser una red pública como Internet. Las claves para esta amplia red son los extremos de API.

Los extremos serían las tomas de corriente en las que se enchufan las aplicaciones.

El número y los tipos de aparatos que se pueden enchufar en las tomas de corriente solo están limitados por la imaginación de los inventores y la capacidad de la red. Del mismo modo, el número de aplicaciones que pueden sacar provecho de los datos extraídos por el extremo de una API solo está limitado por la imaginación de desarrolladores y la capacidad de la infraestructura del proveedor de API.

Veamos un ejemplo. Poco después de que Google ofreciera una API para Google Maps miles de desarrolladores externos produjeron aplicaciones únicas e innovadoras que utilizaban la API e incorporaban la función de mapas de Google directamente en sus aplicaciones. Piense en Think Yelp, Lyft, Tesla, y cualquier otra aplicación que proporciona un mapa con el copyright de Google en la esquina.

Es por este motivo que se hace referencia a menudo a las API como un motor de innovación, especialmente para los Trailblazers de la Integración que ven las muchas API que están disponibles para ellos como piezas de terceros que pueden utilizar para construir nuevos resultados de negocio y nuevas experiencias de cliente.

Economía de API

Dependiendo del volumen de llamadas o alguna otra forma de desglosar los diferentes niveles de servicio, un proveedor como Google podría cargar al desarrollador de la aplicación una cuota por el uso de la API. Esto da lugar a la idea de una economía de API.

Ahora, el desarrollador de la aplicación debe ponderar todos los costos del uso de la API frente al desarrollo de la función desde cero. O bien, como suele ocurrir en la economía de API, el desarrollador puede buscar un proveedor más económico para un servicio similar. Google Maps, por ejemplo, tiene varios competidores conocidos, incluyendo Here.com.

El crecimiento de la economía de API está impulsado por los proveedores de servicio que compiten por satisfacer esta sed por una mayor productividad de los desarrolladores y más datos comunes. Para cada uno de los diferentes tipos de función que se pueden invocar mendiante API (como el procesamiento de tarjetas de crédito, mapas, navegación y traducción), existen a menudo múltiples proveedores de API que compiten por la atención de los desarrolladores de aplicaciones y los integradores ciudadanos. A su vez, cuantas más funciones se proporcionen en el formulario de servicios basados en web, la economía de API está acelerando la tendencia en todo el mundo de aplicaciones compuestas principalmente de API existentes. Cuanto más facil sea acoplar API en la solución final, más ágil resultará adoptar nuevas funciones procedentes de otras API que eleven el listón en cuanto a la capacidad global de la compañía.

El crecimiento de las API antes y ahora

Quizás esté pensando que las API conectables son el mejor invento desde las palomitas de microondas. Quizás se esté preguntando también que, siendo tan maravillosas, ¿cómo es que la industria tecnológica no las inventó antes? Pues resulta que sí que lo hizo.

En la época en la que se desarrolló Unix, era habitual que los programadores invocaran una lógica de negocio de forma remota desde otra máquina a través de una red con una tecnología llamada RPC, o llamada a procedimiento remoto.

¿Está preparado para una sopa de acrónimos importantes? Con el paso del tiempo, RPC dio paso a otras formas solicitudes de datos y de funciones de manera remota, como Network DDE (intercambio dinámico de datos), CORBA (arquitectura de negociación de petición de objetos comunes), intercambio de datos electrónicos (EDI), etc. Y finalmente apareció la denominada XML-RPC (¡hurra! ¡RPC de nuevo!), que evolucionó más adelante para convertirse en lo que conocemos como servicios web, basados en XML y en el protocolo simple de acceso a objetos (SOAP).

Cada vez que aparecía una nueva tecnología de acceso remoto a datos o funciones, la industria pensaba que finalmente se había alcanzado la utopía. Y entonces llegaron las API web como las que usamos en la actualidad, las API que, como mencionamos antes, se basan en funciones que ya están integradas en el protocolo web (HTTP) a través del uso de verbos especiales como GET, PUT y POST. Efectivamente, es el mismo protocolo de Internet que utiliza todos los días para visitar sus sitios web favoritos.

El (posible) futuro de la integración

De modo que, si nos fijamos en la historia reciente, es posible que la forma en que integramos entre sistemas esté a punto de cambiar. Existen dos tecnologías relativamente nuevas similares a las API, pero que difieren del enfoque web preponderante en la actualidad. Una es de Facebook, se llama GraphQL y la otra de Google, denominada gRPC.

Ambas tienen sus propias ventajas sobre las API web actuales. Por ejemplo, GraphQL está inspirada en la idea de un gráfico social y en cómo diferentes elementos de datos como amigos, fotos, lugares de trabajo, etc. forman laberintos de información interrelacionada. GraphQL permite solicitar información de todo un gráfico de datos de una sola vez (frente a los múltiples recorridos de ida y vuelta de solicitudes que necesitan las API tradicionales para conseguir lo mismo).

gRPC por el otro lado tiene sus propias ventajas. Se basa en HTTP/2 (HTTP versión 2), que permite transmitir datos bidireccionalmente. Empleando HTTP/2, gRPC también puede convertir una API en una API de transmisión que envía sus datos a la aplicación consumidora en cuanto esos datos están disponibles. Para algunas aplicaciones en tiempo real, como un teletipo bursátil, esa es una forma mucho más eficiente de obtener datos en lugar de forzar la aplicación a comprobar constantemente si existen nuevos datos disponibles como hacen habitualmente las API tradicionales.

La misma idea con tecnología diferente

Independientemente de que se utilice el protocolo de Internet, GraphQL, gRPC o algún otro enfoque sobre las API aún por inventar, al final, la idea de las API conectables en red consiste en convertir una capacidad de una compañía en un servicio conectable en red que otras aplicaciones puedan tratar de forma remota como una parte externalizada de su experiencia para los clientes. A medida que crecen las partes externalizables (la economía de API), también lo hace su oportunidad de ponerse por delante de la competencia con innovaciones y experiencias que serían difíciles de alcanzar si tuviera que hacerlo todo internamente.

La oportunidad también funciona en sentido contrario. ¿Qué competencias de negocio deberá producir su organización para sí misma y para otros desarrolladores externos como un servicio conectable en red en forma de API? Es literalmente la pregunta del millón, especialmente para aquellos que buscan convertirse en Trailblazers de la Integración.