Header Ads Widget

Ticker

6/recent/ticker-posts

¿En qué se diferencian las API web de las API del sistema?

 


“API” se ha convertido en un término popular en el espacio tecnológico, y por una buena razón: las API permiten una increíble variedad de funciones, extensibilidad y escalabilidad para muchas organizaciones en una amplia gama de industrias. Dicho esto, definir qué es realmente una API en un sentido académico puede ser un poco difícil, ya que hay algunas interpretaciones. La industria habla mucho sobre API, pero rara vez habla de los diferentes tipos de API.

Esta pieza hará precisamente esto, discutiendo dos formas centrales de API: la API web y la API del sistema . Estos dos tipos de API son únicos y, a medida que la nueva tecnología ha difuminado las líneas entre ellos, identificar qué es realmente cada tipo de API se ha vuelto más difícil. Sin embargo, comprender los conceptos básicos detrás de este tipo de API es bastante esencial.

¿Qué es una API?

Una API, o interfaz de programación de aplicaciones, se entiende mejor en términos simples como una interfaz que establece y facilita cómo diferentes sistemas o usuarios de esos sistemas pueden interactuar entre sí. Esta forma y función de comunicación declaradas es necesaria debido a la naturaleza de los programas y aplicaciones en general.

Los programas y aplicaciones normalmente funcionan con respecto a sí mismos y al sistema en el que viven. Son esencialmente egoístas, inteligentes sobre sí mismos, pero se vuelven menos inteligentes una vez que operan en otro lugar. Una aplicación de reproducción de medios solo necesita saber cómo reproducir música; ¿por qué debería importarle si puede transmitir los títulos de su lista de reproducción actual a las redes sociales?

Sin embargo, con el aumento de la demanda de los usuarios hacia la interfuncionalidad, la facilitación de la comunicación entre aplicaciones y otros sistemas se ha vuelto increíblemente importante. No solo es suficiente que un sistema de termostato haga funcionar una unidad de aire acondicionado; a los usuarios también les gustaría verificar el estado de ese termostato de forma remota, establecer horarios y más. Hay un par de formas de hacer esto, pero funcionalmente se reducen a dos enfoques principales: integrados o mediante interconexión.

Sí, uno podría pedirle a cada aplicación o programa que comprenda cómo trabajar con todos los demás programas potenciales a través de un conjunto de instrucciones incorporado, pero en ese punto, esencialmente está replicando una matriz de traducción para cada programa una y otra vez. Este enfoque integrado se ha utilizado en el pasado en aplicaciones y programas orientados al consumidor, razón por la cual los primeros sistemas de software estaban esencialmente vinculados a un conjunto específico de hardware e implementaciones. Como resultado, el software se acopló y fue menos reutilizable. Fue una forma increíblemente pesada de lidiar con las cosas y no promovió la interconexión tanto como promovió la interdependencia.

Hay otro enfoque. Dado que la mayoría de los programas necesitan los mismos métodos básicos para comunicarse y trabajar juntos, podemos tomar esa capa de conexión entre los programas y formar una interfaz completamente separada. Esta interfaz permite que los programas y aplicaciones sean algo egoístas con su atención, simplemente conociendo el método por el cual se comunican con esa interfaz. En otras palabras, reduce la complejidad de la comunicación.

Ese es el concepto central detrás de la API: una capa de traducción que reforma las solicitudes y las instrucciones para transmitirla a otros socios que la acepten.

Una explicación lingüística

Otra forma de pensar en las API es considerar una empresa con componentes multilingües. Imagine que un contador habla francés, el diseñador habla japonés y el gerente habla alemán. ¿Cómo trabaja la organización en conjunto?

En teoría, podría pedirles a cada uno de ellos que aprenda los idiomas de los demás trabajadores, pero esto crea un escenario en el que cada trabajador necesitaría saber al menos tres idiomas (y potencialmente más si desea trabajar con una empresa externa).

Es mejor, entonces, que contrate a un traductor, alguien que pueda traducir cada interacción dentro de un sistema específico de criterios que permita a todos trabajar juntos. Esta capa de traducción facilita el flujo de trabajo y permite a los trabajadores hacer su trabajo de la manera que deseen sin preocuparse por cómo será interceptado, entendido, transformado y transmitido por otros.

Esta es una API.

¿Qué es una API web?

Desde este contexto, definamos qué es una API web. Las API web a menudo se denominan de forma más general "servicios web" y, en esencia, son precisamente eso: un servicio que vive en la web y facilita las interacciones. Son las API que permiten a un usuario, sistema o servicio interactuar con un punto final que luego interactúa con un sistema interno más grande. Estas interacciones se rigen por un conjunto de reglas e instrucciones, lo que permite que una solicitud provenga de un usuario en un sistema completamente diferente en una forma y función que sea conocida y útil.

Por ejemplo, cuando un usuario utiliza un servicio de radio web, su sistema se pone en contacto con el punto final de una API específica, que luego sirve el contenido según lo solicitado y en la forma solicitada. Cuando el servicio de radio web se comunica con otro servicio para obtener algo como créditos de audio o elementos de hipervínculo, no usa sus propias reglas ni un conjunto conocido de interacciones para hacer esto. En cambio, trabaja con otra API a través de sus puntos finales declarados para entregar este contenido.

Este es el concepto de una API web: todas las interacciones se coordinan a través de este sistema web para facilitar interacciones más dinámicas y exitosas. Cuando se discuten las API web, normalmente hablamos específicamente sobre el servicio de contenido a través de HTTP a través de diversas metodologías y paradigmas. REST, GraphQL y gRPC son enfoques de uso común para las API basadas en HTTP.

Si bien los estilos de diseño de API web justifican muchos otros artículos, el panorama moderno se ha dividido aproximadamente en dos categorías generales, independientemente del paradigma o mecanismo: API independientes y API como parte de una oferta. Esto tiene muchos nombres, pero a menudo verá una dicotomía entre las API de un solo uso que existen para cumplir una función en particular y las API que son parte de un producto o servicio (también conocidas como API en forma de plataforma como servicio, API como producto, etc.)

¿Qué es una API del sistema?

Una API del sistema es más parecida a un formato de API tradicional , donde una API toma alguna entrada como guía para manejar las funciones internas de un sistema en particular. En esta forma clásica, una API del sistema puede recibir instrucciones de una aplicación de usuario en el mismo sistema local o una entrada de instrucciones de hardware, como un teclado o una pantalla táctil. En esencia, la API es una capa entre la instrucción de hardware y la instrucción de software y, por lo general, se crea explícitamente para una aplicación limitada.

Es de destacar que con las API del sistema es donde normalmente "viven". Estas API a menudo se proporcionan desde una biblioteca, SDK o algún otro servicio "local". Tenga en cuenta que cuando hacemos referencia a "local" aquí, nos referimos a "local" en términos de la ubicación del sistema en la web: las API web, de manera predecible, ofrecen contenido a través de la web. Por el contrario, las API del sistema generalmente brindan datos al integrarse en un proyecto como parte de una biblioteca utilizada para ejecutar una aplicación. Una metáfora aproximada sería que una API web es una comida para llevar y una API del sistema es una comida casera.

Curiosamente, la línea entre la API del sistema y la API web se ha vuelto bastante borrosa en los últimos años. Muchas API web han reemplazado a las API centrales del sistema, o al menos, se han integrado tan estrechamente que la diferencia se ha vuelto académica en el mejor de los casos. Si bien nos sumergiremos en esto en un momento, vale la pena considerarlo al discutir estas interacciones, ya que la línea se ha difuminado significativamente, lo que hace que las líneas de delineación sean algo complicadas.

Interacciones entre API web y API del sistema

A veces, las API web y las API del sistema interactúan entre sí. Consideremos el flujo de una solicitud de usuario en una colección de API. Primero, el cliente de usuario realiza una solicitud a través de la API web. Esta API tiene un conjunto delineado de interacciones. Si la solicitud del cliente de usuario está dentro de estas interacciones, la solicitud se toma desde el punto final externo al sistema mismo.

Esta API es, en este flujo, esencialmente un enrutador de tráfico inteligente: sabe dónde enviar la solicitud y, en la mayoría de los casos, cuando se tocan una API web y una API del sistema, es en esta etapa cuando el tráfico cruza.

Una vez dentro del propio sistema, la API del sistema transforma la solicitud y promulga la resolución de la solicitud. Estos son los paradigmas básicos de las API web y del sistema: una API web utiliza un esquema mediante el cual los clientes y sistemas web pueden comprender las interacciones con otros clientes y sistemas web. Por el contrario, una API del sistema convierte esto en una interacción que puede ser entendida por el propio sistema. Estos dos dominios distintos: las API web como interconectadas y diversas, las API del sistema como limitadas en conectividad y específicas en propósito y acción, se han desdibujado a medida que más dispositivos han adquirido un enfoque interconectado.

Veamos uno de esos casos.

Dispositivos de Internet de las cosas (IoT)

Quizás el ejemplo más obvio de estas líneas borrosas es el creciente Internet de las cosas (IoT). IoT se basa en un concepto simple: muchos dispositivos pequeños conectados entre sí para realizar diversas tareas, a menudo aprovechando el procesamiento, el almacenamiento y otras funciones "similares a un sistema" fuera del dispositivo. Cada dispositivo suele hacer algo muy específico, por ejemplo, informar la temperatura, exportar registros, etc. Se conecta con otros dispositivos para formar un tipo de "red de dispositivos en malla".

La confusión de la API web y la API del sistema proviene del hecho de que estos dispositivos de IoT están, por definición, conectados a través de API web. Todo se maneja a través de puntos finales en una serie de conexiones en red. Estas API toman solicitudes estructuradas y de forma limitada de varios usuarios, lo que genera una variedad de contenido y respuestas. Pero estas salidas son generadas exactamente por las mismas funciones que normalmente se llamarían API del sistema. En este caso, la API del sistema y la API web son la misma. Para ser más específicos, una colección de dispositivos de IoT puede funcionar como un grupo de recursos pares en forma de una especie de intranet, donde todos los dispositivos se conectan exclusivamente entre sí y a la red local, y solo el dispositivo de borde se conecta realmente con la red local. web.

Si bien este es un caso muy particular, en realidad se ha vuelto más común a medida que los años han progresado también en otros dominios. Las API de sistema conectadas a Internet se dividen muy estrechamente de las API web que también se conectan a los sistemas que tocan, casi hasta el punto en que la diferencia se ha vuelto académica. Los relojes conectados a Internet, los instrumentos que utilizan Bluetooth para conectarse a dispositivos inteligentes para la sintonización y otros dispositivos difuminan la línea de manera tan sustancial que casi se puede decir que operan como un tercer tipo de API por completo; algunos en el espacio de API incluso han tomado para llamar a estas API de dispositivo.

Conclusión

En última instancia, incluso si la diferencia entre las API del sistema y las API web se vuelve borrosa, todavía ayuda a comprender las diferencias principales académicamente. Supongamos que una API toca tanto el sistema como la web. En ese caso, es mejor pensar en la implementación como dos caras de la misma moneda; esto puede tener un impacto marcado en el rendimiento general, la seguridad y el flujo general de la API final y el sistema sobre el que se basa. Comprender la red en general y las partes y sistemas interfuncionales que viven en ella es extremadamente importante.

¿Aclaramos las diferencias? ¿Cree que la diferencia sigue siendo lo suficientemente sustancial como para justificar una conversación? ¿Tiene una interpretación diferente? Nos encantaría saber de ti. ¡Háganos saber en la sección de comentarios a continuación!

Publicar un comentario

0 Comentarios