Header Ads Widget

Ticker

6/recent/ticker-posts

7 tendencias de diseño de API en crecimiento


 El mundo de las API está en constante evolución y mutación. Los datos con los que tratamos en la década de 1990 no son los mismos que los datos con los que podríamos tratar en 2017, y debido a esto, nuestras API han tenido que cambiar drásticamente sus enfoques. Estos cambios son problemas en la arquitectura de la API. espacio de la los que recién ahora nos estamos dando cuenta.

Afortunadamente, estos problemas se están resolviendo con nuevas tecnologías, enfoques y conceptos y, como tales, merecen cierta discusión. En este artículo, hablaremos sobre 7 tendencias de diseño de API en crecimiento y lo que significan dentro del contexto del diseño de API anterior. . Discutiremos las implicaciones de incorporar nuevos diseños de API y lo que significan para la API moderna y sus aplicaciones futuras.

Esta pieza se inspiró en gran medida en una presentación realizada por James Higginbotham en APIStrat 2017 , titulada API Design in the Age of Bots, IoT y Voice . Sus diapositivas se pueden ver en SlideShare y sirven como un excelente compañero para la discusión que vamos a tener hoy.

La lente del pasado

El mundo de las API es en gran parte uno de evolución e iteración. No debería sorprender, entonces, que muchos de los problemas en el espacio de las API modernas se deriven del hecho de que hemos estado poniendo fin a las desigualdades y problemas de implementaciones y enfoques anteriores. En la década de 1990, el concepto de Integración de objetos distribuidos reinó supremo, permitiendo que los recursos se recopilaran y vincularan entre sí para que los usuarios los manipularan e integraran de manera más completa.

Después de esto, a principios de la década de 2000, el movimiento y el soporte de SOAP para la integración de corporación a corporación y el intercambio de recursos hicieron que los sistemas de estilo DOI fueran algo obsoletos para la mayoría de los casos de uso. SOAP reinó en lo alto para muchos casos de uso , pero en sí mismo tenía problemas importantes que requerían que se desarrollaran, iteraran e implementaran más sistemas en el futuro previsible.

Con la llegada de la década de 2010, las API se alejaron de las API con estado diseñadas para pilas de red y pasaron al concepto de diseño sin estado con un enfoque en la integración de datos móviles. Los teléfonos inteligentes, que alguna vez se consideraron un campo limitado de las telecomunicaciones, ahora tenían la promesa de micro-supercomputadoras en la palma de nuestras manos, y nuestras soluciones de datos debían escalar adecuadamente para satisfacer esta demanda. Los desarrolladores adoptaron rápidamente el diseño REST como un estándar de facto, y las soluciones como GraphQL prometieron negar muchos de los problemas con SOAP y soluciones anteriores.

Sin embargo, el problema fundamental en todo esto es que todavía estamos atrapados en los primeros diseños de Internet y de las API que impulsan la comunicación; podemos iterar más complejidad, pero al final del día, nuestra mansión moderna es todavía construido sobre una base de 30 años.

CRUD - Por qué es Cruddy

Las API están fundamentalmente atascadas en la tierra de CRUD , es decir , crear, leer, actualizar y eliminar . En el proceso normal de una API, el usuario solicita que se cree un recurso, que lea un recurso, que se actualice un recurso o que se elimine el recurso, y eso es todo lo que solicita. Cada función que hará una API centrada en CRUD es una combinación simple de esos cuatro elementos, y nada más.

Las solicitudes modernas de interfaces digitales no encajan en sus operaciones CRUD típicas.

Esto estaba bien a principios de la década de 2000 cuando todo lo que necesitábamos era la marca de tiempo en un archivo, pero el panorama de los medios modernos requiere más permeabilidad y una mayor flexibilidad en la forma en que manejamos la información. Debido a esto, el modelo CRUD es ineficiente porque ya no refleja para qué usamos realmente las API.

La interfaz con asistentes de voz como Alexa requiere recopilaciones de recursos y funciones similares a la IA para discernir la relevancia, el interés y el valor; esto no es algo que se haga fácilmente con un sistema CRUD, por lo que CRUD no es la estructura de diseño de los sistemas frontend que conducir Alexa. Otras implementaciones de este tipo, que van desde Google Home hasta dispositivos Apple interconectados, muestran que CRUD ya no es aplicable a todos los requisitos de diseño.

Con todo esto dicho, ¿qué alternativas tenemos?

1. Hipermedia y HATEOAS

Hypermedia y HATEOAS (Hypermedia as the Engine of Application State) es una respuesta a este dilema, y ​​es una solución que se ocupa principalmente de la vinculación de recursos. En una arquitectura API de CRUD clásica, esto no es necesariamente algo que se pueda hacer fácilmente. En pocas palabras, hipermedia proporciona una respuesta más detallada a una consulta simplificada al incluir enlaces hipermedia con cada respuesta de forma dinámica.

Como ejemplo, un usuario puede enviar una solicitud de información sobre un proyecto. Un sistema hipermedia responderá a ese proyecto con la información solicitada, así como el estado del proyecto, enlaces a recursos relacionados y, a veces, incluso opciones para la manipulación de ese proyecto.

A menudo, estos proyectos reciben una metaetiqueta o algún otro método de vinculación, lo que permite interacciones aún más complejas gobernadas por relación, tipo y función. En muchos sentidos, esto imita (y podría decirse que podría ser el precursor de) las aplicaciones modernas de inteligencia artificial que vinculan inteligentemente los recursos por relación. Los tipos de hipermedia como HAL, Siren HAL, Collection + JSON o Atom / AtomPub proporcionan un medio estándar para implementar esto.

Para obtener más información, lea: Descubra cómo implementar hipermedia en su API

2. Suscripciones a eventos

En este tipo de enfoque de diseño, la interacción habitual entre la API y el usuario se invierte. En una arquitectura tradicional, el usuario llega a la API, realiza una solicitud y luego termina voluntariamente esa interacción. La relación real entre usuario y prestador es terminal y temporal, por lo que está expresamente limitada.

En una arquitectura de suscripción de eventos , esta relación se invierte. Si bien el usuario hace el contacto inicial, la relación no es temporal y terminal, se crea una relación continua en la que el usuario se suscribe a la información y sus actualizaciones futuras.

En este tipo de diseño arquitectónico, un usuario se suscribe a la entidad , y cuando se realiza un cambio, los cambios se dan en los metadatos y se proporcionan como una representación de recursos actualizada. En este caso, la API tiene dos funciones principales: en primer lugar, la API tiene la función de entregar los recursos al usuario que los solicita y, en segundo lugar, la API sirve como agente de mensajes para recopilar las adiciones de los editores y actualizar a los que se han suscrito.

Esto cambia fundamentalmente la relación entre el usuario y la API, y asegura una experiencia activa y continua para los usuarios suscritos.

Relacionado: 5 formas de implementar una arquitectura impulsada por eventos

3. Diseño de API basado en la capacidad

Muchas de las tendencias de diseño discutidas en este artículo son modificaciones de las metodologías y enfoques tradicionales de CRUD para extender la función. El diseño de API basado en capacidades, sin embargo, evita los métodos CRUD por completo. La arquitectura basada en la capacidad se basa en las funciones que realmente requiere el usuario y, por lo general, es una serie de relaciones personalizadas o instrucciones basadas en un conjunto limitado de funciones dentro de una mayor variedad de funciones, servicios y subprogramas predefinidos.

Como ejemplo, existen numerosas integraciones que permiten compartir tweets de una lista de cuentas de Twitter de forma rutinaria, crear una tarjeta Trello única semanalmente, guardar automáticamente los archivos adjuntos de Gmail en Dropbox como un archivo único e incluso actualizar archivos locales en un Copia de seguridad de Dropbox cuando se cambia un archivo remoto: todo esto es posible gracias a las API basadas en capacidades ; el tipo de interacciones no se ajusta bien a un sistema CRUD típico.

4. Negociación de contenido

Si el diseño de API basado en capacidades es una forma de diseñar para la especificidad de la aplicación, la negociación de contenido es posiblemente una forma de diseñar para la falta de especificidad. La negociación de contenido es un proceso en el que un conjunto dado de posibles variaciones de entrada se reduce a una única entrada probable que sea la mejor representación posible de esa solicitud para la entidad solicitante.

"HTTP tiene disposiciones para varios mecanismos de" negociación de contenido ", el proceso de seleccionar la mejor representación para una respuesta determinada cuando hay varias representaciones disponibles".
RFC 2616 Fielding

Para obtener una explicación detallada de la negociación de contenido, lea: Negociación de contenido para la longevidad de la API web

5. API de contexto frontend

Mientras que la negociación de contenido se centra en ofrecer contenido al usuario que lo solicita, las API de contexto frontend  permiten interacciones aún más dinámicas. Una API de contexto frontend asignará las API a los dispositivos y gestionará estas sesiones interactivas de  forma dinámica . La principal de estas formas es solicitar contenido e información adicional para enmarcar la solicitud: una API de contexto de frontend esencialmente permite solicitudes más complejas y detalladas, y luego las transfiere en un formato empaquetado al backend.

En última instancia, esto da como resultado una situación en la que se perfora al usuario para obtener información para completar la solicitud que realmente desea, en lugar de la solicitud que creó. Esto puede parecer contradictorio, después de todo, el usuario debe saber exactamente lo que quiere, pero en última instancia da como resultado solicitudes más completas y, por lo tanto, datos entregados con mayor precisión.

6. API en el dispositivo

Una API interna en el dispositivo maneja las versiones y la sincronización entre el repositorio en línea y el local. Un buen ejemplo sería el de almacenar y reenviar para sincronización fuera de línea.

Esto no se puede manejar de una manera fácil con CRUD, porque detalla el control de versiones interno exclusivo del repositorio externo, y requiere control de versiones y actualización que de otro modo requeriría múltiples API interactivas. Sin embargo, si la API en sí está construida desde el principio para estar en el dispositivo y trabajar en conjunto como un par desarticulado, esto se hace mucho más fácil.

Otra implementación sería un bot que sirva como punto de entrada interno a la propia API. Un ejemplo de esto sería en Slack, cuando habla con el bot interno para programar una reunión, guardar un archivo o realizar alguna otra función. No está hablando expresamente con una API per se, pero no está hablando con una persona; está indicando a una API que haga algo en el dispositivo en su nombre, y este comando se comunica al sistema en su conjunto.

Relacionado: Protección de dispositivos médicos de IoT

7. Bots como API de próxima generación

Los bots ahora sirven para una gama cada vez mayor de propósitos y, a medida que Internet crece y se vuelve más exigente, es de esperar que las API se vuelvan más numerosas junto con ellos . La suposición actual de que los bots están hablando con humanos puede no ser siempre cierta: en aplicaciones futuras, los bots pueden hablar con bots y las aplicaciones podrían hablar con bots como si fueran API.

Estas comunicaciones aprovechan más que una sola API: recopilan muchas API y muchos bots en una sola red en la que su suma colaborativa es mayor que su conjunto combinado. Esto se volverá cada vez más estándar a medida que los bots se vuelvan más inteligentes y capaces, y a medida que la IA se desarrolle en el futuro, es probable que adopte la forma de un bot que interactúe con otros bots en lugar de que una IA acepte solicitudes.

Relacionado: ¿Cómo podría la inteligencia artificial mejorar el diseño de API?

Conclusión

El simple hecho es que CRUD ya no es el más aplicable y capaz de diseñar enfoques arquitectónicos como solía ser. Internet está evolucionando, al igual que las necesidades del usuario medio. Con esta evolución de la necesidad, los desarrolladores de API deben comenzar a considerar metodologías y enfoques de diseño adicionales. En el futuro, no hacerlo puede resultar en la propagación de medidas provisionales y curitas diseñadas para hacer que CRUD haga cosas que realmente no está destinado a hacer.

Dicho todo esto, estas 7 tendencias son fuertes y prometen por decir lo menos. Será interesante ver lo que estos diseños crean en última instancia, y si podrán o no liberarse por completo del arquetipo CRUD. ¿Qué piensas? ¿CRUD sigue siendo aplicable para estos casos de uso modernos? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios