Header Ads Widget

Ticker

6/recent/ticker-posts

Una historia de cuatro diseños de API: análisis de arquitecturas de API comunes

 

un-cuento-de-cuatro-diseños-nordic-apis

En el mundo de las API, la forma en que diseñamos e implementamos el código es de suma importancia. Comenzar el desarrollo sin una perspectiva, un enfoque o una consideración de diseño arquitectónico adecuados podría generar redundancia, complejidad y restricciones innecesarias. Sin embargo, al implementar una de varias arquitecturas de diseño comunes, podemos guiar nuestro estilo de API en una dirección más coherente, disminuyendo el tiempo de desarrollo, aumentando la eficiencia del desarrollador y creando un ciclo de vida de API optimizado .

Cuatro enfoques, una teoría unificada

En el cuento clásico urdu del que esta pieza toma su nombre, " Un cuento de cuatro derviches ", un rey abatido llamado Azad Bakht abandona su castillo decadente en busca de sabiduría. Durante su viaje, se encuentra con cuatro sabios, cada uno equipado con una experiencia, una historia y un punto de vista únicos sobre el mundo en general. Sus historias lo guían a la felicidad, colocándolo en un camino próspero hacia adelante.

Asimismo, en el mundo del diseño de API, existen cuatro estilos de diseño arquitectónico primarios, cada uno con su propia experiencia de usuario, su propia historia y su propio enfoque del mundo de las aplicaciones web y las integraciones de API. Aunque estos diseños no son mutuamente excluyentes (un tema que discutiremos más adelante en este artículo), comprender cómo se diferencian entre sí puede ayudar a informar su decisión sobre qué enfoque de diseño tomará y si su elección lo colocará en un camino similar de felicidad y prosperidad.

Diseño de identificador uniforme de recursos (URI)

El estilo URI es un paradigma de diseño muy común: debido a la relativa simplicidad de invocar solicitudes a través de operaciones HTTP comunes, los desarrolladores a menudo prefieren el sistema sobre otros por el bien de su propio flujo de trabajo. Muchas de las operaciones más básicas que un desarrollador podría desear se asignan directamente a los métodos y funcionalidades HTTP: las invocaciones de creación, lectura, eliminación y actualización están vinculadas a funciones de protocolo HTTP integradas, lo que crea un conjunto extremadamente simplificado de operaciones sobre las que actuar. la naturaleza relativamente más expuesta de un estilo de API orientado a objetos / recursos inherente a la arquitectura URI.

Además, los diseños centrados en URI tienen una propensión incorporada a autodocumentarse. Como el estándar para los diseños de URI incluye los llamados sistemas "pirateados", o sistemas que permiten la manipulación por parte del usuario final, estas API a menudo se modifican y manipulan de manera extensible, lo que genera una cantidad relativamente grande de documentación de usuario y posibilidades de revisión.

Si bien el diseño de URI es común y tiene muchas facetas buenas, está lejos de ser perfecto, y muchas de las fallas inherentes al diseño casi exigen que otros diseños más extensibles se integren como un socio del URI (o un reemplazo en conjunto).

La simplicidad puede hacer que un sistema sea más fácil de administrar e implementar, pero no necesariamente lo hace útil: una API que no es extensible es una API que está muerta en el agua . Al intentar hacer una API con una serie compleja de interacciones e invocaciones utilizando un sistema tan restrictivo, la simplicidad pronto se echa por la ventana. Los diseños de API se vuelven cada vez más complejos. La curva de aprendizaje que alguna vez fue un beneficio es cada vez más una desventaja, y lo que son solicitudes simples en otros estilos de diseño pronto se inflan a cadenas de múltiples solicitudes e invocaciones.

Aún así, con todas sus ineficiencias e inconvenientes, el diseño de URI es una opción lo suficientemente decente cuando se sabe que todas las interacciones con la API se llevarán a cabo a través de HTTP; el mejor ejemplo de este uso es la arquitectura de diseño de API REST . Dado que el diseño de URI es innecesariamente complejo cuando la API se expande más allá de aplicaciones simples, de propósito único o de alcance limitado, en la mayoría de los casos de uso es mejor combinarlo con otros diseños.

Nuestra infografía define arquitecturas REST y SOAP

Diseño de arquitectura impulsada por eventos (EDA)

En parte como respuesta a la naturaleza extremadamente limitada del diseño de URI, la arquitectura basada en eventos se ha vuelto popular en los últimos años a medida que los desarrolladores apuntan a crear aplicaciones más receptivas. La diferencia clave entre el enfoque basado en eventos y sus contemporáneos es que este enfoque es de doble sentido . Mientras que otros sistemas dependen de que el cliente o el servidor escuche y responda a los eventos en una relación previamente acordada (por lo general, una que coloca a un lado como el "actor" y al otro como el "sobre el que se actúa"), el El diseño requiere que tanto el cliente como el servidor escuchen los nuevos eventos.

Esto, junto con el soporte implementado para la mensajería asincrónica (mensajería realizada a través de un sistema de colas, eliminando la necesidad de una respuesta de cualquiera de los socios para continuar enviando y recibiendo) lo convierte en una API muy poderosa, capaz de invocaciones complejas, grandes transferencias de datos, y metodologías de transporte innovadoras.

Al igual que con otros diseños de API, la arquitectura dirigida por eventos se puede operar sobre la pila de protocolos HTTP utilizando tanto un encabezado como un cuerpo (en este caso, un encabezado y un cuerpo del evento ). Sin embargo, todo el potencial del diseño surge realmente cuando se utiliza sobre otras metodologías y sistemas. Como tal, la implementación de HTTP a menudo se evita en favor de protocolos de transporte más potentes. El protocolo WebSocket, por ejemplo, es un sistema impulsado por eventos que se ha incorporado en gran medida a la especificación HTML5, lo que permite la transferencia de grandes cantidades de datos con una sobrecarga relativamente mínima mediante la comunicación asincrónica.

Uno de los ejemplos más populares del estilo impulsado por eventos es Java Swing. La API de Java Swing, diseñada específicamente para crear una interfaz gráfica de usuario para programas Java , utiliza una nomenclatura de API que delimita entre "ActionListener" y "ActionEvent". Uno de los ejemplos comunes utilizados para demostrar la naturaleza reactiva de Java Swing es la creación de un botón que un usuario puede presionar, desencadenando una reacción del servidor y mostrando un mensaje tanto para el cliente como para el servidor en parte:

La clase pública FooPanel extiende JPanel {

public FooPanel () {

súper();

    JButton btn = new JButton("Click here!");  
    btn.addActionListener(new ActionListener() {  
        public void actionPerformed(ActionEvent ae) {  
            System.out.println("Alert: button has been clicked.");  
        }
    });  
}

}

Con este formato de clase anónimo, se puede proporcionar un número casi infinito de opciones reactivas al servidor y al cliente, lo que permite interacciones complejas en un número relativamente pequeño de invocaciones. Sin embargo, al igual que el estilo URI, el estilo EDA tiene serias limitaciones: debido a que utiliza protocolos y sistemas adicionales para comunicarse, requiere mucha más infraestructura que el sistema URI.

Si bien esta opción de diseño es perfecta para aplicaciones móviles o aquellas dentro del amplio Internet de las cosas (IoT) , la complejidad del sistema puede desperdiciarse si la funcionalidad de la API es increíblemente limitada. Si su API es simplemente un diseño orientado a solicitudes / respuestas, implementar un sistema EDA como única opción podría ser más problemático de lo que vale la pena.

Diseño de arquitectura hipermedia (HA)

La arquitectura hipermedia es un enfoque intermedio entre la arquitectura basada en eventos y el diseño de URI, mientras que el diseño de URI se centra principalmente en los objetos y sus solicitudes, la arquitectura hipermedia se centra en las tareas y el flujo entre ellos . Piense en una API de Hypermedia como un mapa: al navegar por las calles, un mapa puede brindarle opciones de navegación a una ruta específica y una metodología específica para llegar allí. De manera similar, una API de Hypermedia ayuda a navegar el flujo de trabajo y proporciona una plantilla rica en funciones para solicitudes de información e invocaciones de funciones .

En el contexto del mundo más amplio de las metodologías API, el diseño de Hypermedia es especial. Mientras que otros sistemas de medios se basan en URI definidos, documentación específica del desarrollador y estrictas restricciones en la estructura y organización del mensaje, las arquitecturas Hypermedia crean sus propios URI dinámicos , utilizan semántica de enlaces basada en gran medida en medios y designaciones en evolución, y utilizan estructuras de mensajes de forma libre como determinado tanto por el desarrollador como por las necesidades del sistema.

Sin embargo, lo más importante es que los diseños de Hypermedia están conceptualmente orientados hacia servicios con una vida útil excepcionalmente larga. Debido a que el sistema de API en sí está diseñado para evolucionar para satisfacer las necesidades de una base de usuarios en constante cambio y crecimiento , un sistema de API de Hypermedia podría, teóricamente, evolucionar durante años después de su concepción inicial, admitiendo aplicaciones desarrolladas tanto en su infancia como en su etapa posterior. años.

La advertencia a todo esto, y es bastante grande, es que un diseño de API de Hypermedia es solo eso: un diseño. Una API diseñada de esta manera funciona en su propio pequeño universo, con sus propias fortalezas y debilidades. Debido a esto, nunca habrá un soporte o herramientas verdaderamente robustos y maduros para un sistema Hypermedia puro a menos que el desarrollador los construya específicamente. A pesar de esto, o a pesar de ello, algunos desarrolladores han intentado crear estándares, protocolos y sistemas ( como HATEOAS ) destinados a vincularse con herramientas generales para llenar este vacío.

Leer más: Cómo utilizar las API de hipermedia para ofrecer un diseño adaptable

Estilo de tunelización

El más antiguo de estos cuatro estilos, el estilo Tunneling, funciona como un sistema de llamadas a procedimiento remoto (RPC) organizado en un formato de mensaje XML . Las API de tunelización permiten la localización de contenido, donde los hosts distantes utilizan las llamadas RPC para solicitar acceso como si el servidor que proporciona los datos fuera local; esto se logra mediante la generación de código proxy basado en el formato de mensaje manejado por una variedad de proveedores.

Además, debido a que Tunneling Style utiliza varios métodos de transporte como base para el transporte de nivel superior, las API de Tunneling Style son libres de usar una mayor variedad de protocolos, sockets o sistemas para codificación, transporte de bajo nivel y comunicación, como JMS. o TCP / IP, que otras opciones de diseño. Este formato de diseño, independientemente de transporte, se llama “ agnóstico transporte ” - el sistema no le importa cómo se codifica o se transporta los datos, siempre y cuando sea compatible con el método de la comunicación física y la otra parte es capaz de utilizarla.

El más famoso de los formatos de API que utilizan este estilo es la arquitectura SOAP , que está diseñada en gran medida para transacciones verificadas (es decir, casos en los que el cliente debe estar autenticado o verificado y las transacciones deben estar autorizadas) y el manejo de grandes datos (como el procesamiento de medios o intercambio). Sin embargo, el formato de mensaje en la arquitectura SOAP es ligeramente diferente de las API de estilo de túnel estándar en que el formato de mensaje para SOAP está codificado y restringido según las especificaciones del lenguaje de definición de servicios web (WSDL) .

Existen varios inconvenientes importantes al utilizar el sistema de tunelización. Estos sistemas suelen ser de gran peso y generan solicitudes y respuestas extremadamente detalladas. Los sistemas de tunelización, en particular SOAP, suelen ser demasiado complejos para muchas aplicaciones en las que sistemas como el diseño del identificador uniforme de recursos serían más eficaces. Aunque esto no es un problema en sí mismo cuando se trata de aplicaciones individuales, los conjuntos de aplicaciones o servicios de red pueden explotar rápidamente en complejidad y en el esfuerzo necesario para mantener y brindar soporte.

Lo más significativo es que los sistemas de tunelización exponen la seguridad de formas más directas que otros sistemas. Los usuarios de SOAP generalmente utilizan la funcionalidad a través de solicitudes POST. Dado que estas solicitudes se doblan en un sobre para su transporte, es difícil determinar si la solicitud es para datos o para un propósito malintencionado. Esto se corrige con seguridad, pero esta es una capa adicional de servicio pesado sobre un diseño ya pesado; otros sistemas, como REST, pueden utilizar solicitudes en el formato GET, lo que limita su acceso a una recuperación simple.

Muchas de estas desventajas se pueden reducir un poco simplemente controlando la forma en que se usa su API e implementando los procedimientos de seguridad adecuados , pero en general, el diseño es inherentemente menos seguro que otros. Esto surge de la naturaleza simple del propósito: SOAP fue diseñado para un entorno informático distribuido, no un entorno punto a punto. Las llamadas y la funcionalidad de la API a menudo caen en una extraña área gris de funcionalidad de red de "punto a punto ad-hoc", lo que hace que el uso de SOAP en la era moderna sea una relegación de funciones y propósitos especiales.

Un enfoque híbrido

En algunos casos, un solo enfoque homogéneo no es efectivo: los sistemas evolucionan y cambian en funcionalidad y demandas a medida que cambia la base de usuarios, y lo que alguna vez fue apropiado para el sistema en general puede volverse rápidamente obsoleto. En consecuencia, a medida que los sistemas se vuelven más complejos, también lo puede hacer su API, alejándose de la elección de diseño homogéneo y más hacia un diseño heterogéneo.

Aunque cada uno de los cuatro diseños que hemos discutido en esta pieza son efectivos en su propia gama limitada de aplicaciones, son solo una pieza del rompecabezas más grande: cada uno tiene sus propias advertencias, sus propias fortalezas y debilidades, y sus propias limitaciones. gama de aplicaciones apropiadas. La buena noticia es que se pueden hibridar muy fácilmente si la API está diseñada de tal manera que lo admita.

Tomemos una API de ejemplo. Supongamos que estamos desarrollando una API de comercio electrónico diseñada para manejar grandes cantidades de datos de usuarios, generar informes de usuarios y vincularlos con los servicios de crédito y débito de los principales bancos. Si estuviéramos diseñando nuestra API de manera homogénea, podríamos elegir muy fácilmente un estilo único que lo hace todo bien, pero solo unas pocas cosas bien. En este caso, la elección clara sería el Diseño de Túneles, debido a que la arquitectura SOAP proporciona autenticación y autorización del cliente a través de la metodología de comunicación incorporada y los diversos sistemas de soporte que contiene.

¿Y si diseñáramos nuestra API de forma heterogénea? Nuestro sistema sería mucho más complejo, sin duda, pero ¿cuál sería el beneficio de esta complejidad? En primer lugar, su experiencia de usuario sería muy diferente. SOAP (como con otros diseños de tunelización) es lento y pesado, y no necesariamente está orientado a dispositivos móviles. Si diseñamos un sistema de banca móvil enfocado en un sistema Hypermedia, podemos crear una experiencia móvil rápida y amigable. Luego, podemos utilizar ese sistema para vincularlo a una API de URI directa para comunicarnos con los bancos, limitando posibles problemas de seguridad y creando un búfer entre el usuario y la institución financiera con la que están contactando. Finalmente, podemos tomar la generación de informes y plantarla firmemente en una API Tunneling, lo que permite la recopilación y comparación de datos a largo plazo.

Sin embargo, la advertencia del enfoque es que la complejidad no siempre es algo bueno. Un sistema como este, si bien proporciona una mejor experiencia para los usuarios móviles, una experiencia más rápida para todos los usuarios y una interfaz más segura, es extremadamente complejo para un desarrollador. Básicamente, ha creado tres micro API vinculadas a un servicio central; esto no es necesariamente algo malo, pero es mucho más complejo que una sola elección, y las repercusiones deben considerarse con sinceridad práctica.

Descubrir: ¿Cuál es el futuro del espacio API?

Conclusión

Hemos discutido una variedad de opciones de diseño, cada una de las cuales presenta fuertes fortalezas y algunas serias debilidades. Si bien cada uno de estos sistemas es poderoso por derecho propio, la creación de un sistema heterogéneo puede proporcionar una API mucho mejor a largo plazo, a costa de una complejidad adicional.

Sin embargo, funcionalmente, solo el desarrollador de una API puede conocer su mejor enfoque. Tener en cuenta estos puntos puede ayudarlo a tomar una decisión informada, pero en última instancia, será su propósito, su conocimiento de la base de usuarios y su análisis en profundidad de las necesidades del sistema lo que determinará su diseño arquitectónico.

Integre estos diseños desde el principio en su API, intégrelos correctamente y continúe apoyándolos; si lo hace, su API florecerá absolutamente en el amplio y maravilloso mundo de la World Wide Web.

Otras lecturas

  • Ejemplo de Microsoft de una llamada API realizada utilizando metodologías de tunelización
  • Definición de arquitectura dirigida por eventos (EDA)
  • Ejemplo de enfoque híbrido usando llamadas URI de Hypermedia
  • Documentación de ejemplo para la API híbrida utilizada por Paypal
  • Sawyer Bateman presentando en las API nórdicas: lecciones aprendidas al rediseñar una plataforma API

Publicar un comentario

0 Comentarios