Los estilos de API son un tema de mucha controversia. La mayoría de los profesionales de API están familiarizados con el debate REST vs GraphQL , pero eso sin mencionar los innumerables estilos que existen. La buena noticia es que existe un proceso simple y objetivo para delimitar el mejor estilo (o estilos) para su próximo proyecto de API. En el Platform Summit 2019 en Estocolmo, el consultor experto en API Zdenek “Z” Nemec compartió este proceso con nosotros, analizando los atributos de ocho estilos de diseño de API diferentes .
El campo de juego
Para su charla, Zdenek eligió comparar y contrastar ocho de los estilos de diseño de API más populares. Es cierto, dice, comparar estos estilos es como comparar "manzanas y naranjas ... y plátanos", en el sentido de que algunos son realmente estilos arquitectónicos, mientras que otros son marcos o protocolos que influyen mucho en la naturaleza de la API.
Entonces, ¿qué estilos hay que considerar? La selección de Zdenek comienza con las API web : REST y las llamadas REST . Luego, están las API de consulta , que consisten principalmente en GraphQL. Luego vienen las API de publicación y suscripción , incluidas Kafka y WebSub . Finalmente, hay dos API de RPC , SOAP y gRPC , así como también una simple transferencia de archivos antiguos .
Restricciones, propiedades y consideraciones
El modelo de Zdenek para elegir estilos de API gira en torno a restricciones, propiedades y consideraciones. Después de todo, un estilo arquitectónico es en realidad solo "un conjunto de restricciones que, al aplicarlas, le brindan un sistema con ciertas propiedades". (Dejaremos las consideraciones a un lado por un segundo).
Considere los siguientes ejemplos de esta relación entre restricciones y propiedades:
- Una API que está desacoplada (restricción) es inherentemente modificable (propiedad)
- Una API sin estado (restricción) es inherentemente confiable (propiedad) y escalable (propiedad)
- Una API que implementa una interfaz uniforme (restricción) es inherentemente simple (propiedad)
Por supuesto, las restricciones también pueden resultar en propiedades negativas. Por ejemplo, la baja eficiencia es una propiedad que puede surgir de la restricción de una interfaz uniforme. Sin embargo, para elegir el estilo de API adecuado, Zdenek recomienda que se concentre en lo que sí desea (propiedades favorables) y no en lo que no desea.
Para elegir qué propiedades desea, observe las limitaciones de su organización en cuatro áreas diferentes. Esto comienza con las limitaciones comerciales , como los casos de uso, los requisitos del cliente, el tiempo de comercialización deseado y la estrategia de su empresa. También considere las limitaciones de dominio , como regulaciones gubernamentales o problemas específicos de dominio. Luego, observe las limitaciones culturales , como la exageración del estilo, el conocimiento de los profesionales y el apoyo de los demás. Por último, pero no menos importante, revise las limitaciones de complejidad , incluida la dificultad de estilo, la necesidad de escalabilidad y la complejidad algorítmica.
(Zdenek se refiere a estas limitaciones como "restricciones de producto", pero nos referimos a ellas como limitaciones para evitar la confusión con las restricciones heredadas de estilo discutidas anteriormente).
Según sus hallazgos, puede apuntar a construir una API con propiedades específicas como portabilidad (la capacidad de moverse de un entorno a otro), visibilidad (la capacidad de analizar y administrar el tráfico interno) y seguridad de tipos (la capacidad para reconocer y rechazar tipos de datos incorrectos).
Algunas de las propiedades más evidentes que puede buscar incluyen:
- Actuación
- Escalabilidad
- Sencillez
- Modificabilidad
- Fiabilidad
- Descubribilidad
- Facilidad de desarrollo
- Costo
De menor importancia son las consideraciones que mencionamos anteriormente. Si bien las propiedades afectan directamente la naturaleza de su API, las consideraciones son cuestiones secundarias de implementación relacionadas con el estilo en cuestión. Incluyen:
- Madurez
- Preparación empresarial
- Estampación
- Comunidad
- Recursos específicos de estilo
- Facilidad de externalización
Rasgos de ocho estilos de API
La receta para elegir la API correcta, dice Zdenek, es simple: piense en las propiedades que desea obtener (y las consideraciones que pueden afectar su decisión) y sabrá qué estilo elegir. Por supuesto, para hacerlo, necesitará saber dónde se encuentran los ocho estilos de API en cuestión en términos de restricciones, propiedades y consideraciones ...
DESCANSO
Restricciones: cliente-servidor, sin estado, almacenable en caché, sistema en capas, código a pedido, interfaz uniforme
Propiedades: rendimiento, simplicidad, escalabilidad, visibilidad, portabilidad, capacidad de descubrimiento, modificabilidad, confiabilidad
Consideraciones: madurez, preparación empresarial, comunidad, facilidad de publicación
Comentarios de Z ': REST es excelente para construir un sistema escalable que dure. También es un estilo relativamente flexible y maduro, por lo que es bueno para cosas como la negociación de contenido, multimedia y autenticación de primera línea.
El llamado DESCANSO
Restricciones: cliente-servidor, sin estado, almacenable en caché, sistema en capas, código a pedido, interfaz uniforme
Propiedades: rendimiento, simplicidad, escalabilidad, visibilidad, portabilidad, descubrimiento, confiabilidad
Consideraciones: madurez, preparación empresarial, comunidad, facilidad de publicación, recursos específicos de estilo, herramientas
Comentarios de Z ': El llamado REST es lo que la mayoría de los proveedores de API están haciendo, ya que seguir el protocolo HTTP le brinda todas las propiedades de REST, una interfaz uniforme de barra. Desafortunadamente, la ausencia de esta restricción significa que el llamado REST ofrece poca modificabilidad. Evite usar este estilo; en su lugar, opte por REST o GraphQL.
GraphQL
Propiedades: Facilidad de desarrollo, costos, seguridad de tipo
Consideraciones: comunidad, herramientas
Comentarios de Z ': GraphQL ofrece herramientas increíbles y una gran experiencia de desarrollador. Es rápido de configurar y consumir y funciona bien para la comunicación backend-frontend. Sin embargo, no evoluciona tan bien como REST.
Apache Kafka
Propiedades: rendimiento, visibilidad, escalabilidad, descubrimiento, confiabilidad, seguridad de tipos
Consideraciones: preparación empresarial
Comentarios de Z ': Kafka es un estilo de publicación-suscripción de tendencia que es rápido, confiable y escalable. Si bien tiene todos los beneficios de un sistema basado en mensajes, y almacena los mensajes de forma permanente, no es excelente para la externalización / publicación y requiere mucha destreza en Java.
WebSub
Propiedades: sencillez, escalabilidad, visibilidad, portabilidad, capacidad de descubrimiento, modificabilidad, confiabilidad
Consideraciones: madurez, preparación empresarial, facilidad de publicación
Comentarios de Z ': WebSub es otro estilo de API de publicación-suscripción. Heredado de REST, funciona bien incluso cuando se externaliza. También es independiente del idioma. Sin embargo, ciertamente no es tan eficiente como Kafka.
JABÓN
Propiedades: visibilidad, descubrimiento
Consideraciones: madurez, preparación empresarial, herramientas, comunidad, recursos específicos de estilo
Comentarios de Z ': Puede que no sea el estilo más moderno, pero SOAP todavía tiene sus usos. Se presta bien para construir sobre las infraestructuras (y culturas) empresariales existentes, especialmente para integraciones uno a uno. Sin embargo, para una estrategia a más largo plazo, asegúrese de considerar otros estilos.
gRPC
Propiedades: rendimiento, simplicidad, fiabilidad, seguridad de tipos
Consideraciones: madurez, preparación empresarial, comunidad
Comentarios de Z ': gRPC es un marco RPC básico respaldado por Google. Si bien ofrece un rendimiento excelente, justifica reinventar gran parte de lo que ya ofrecen REST o GraphQL. No es ideal para aplicaciones web o cuando un intermediario de mensajes sería útil.
Transferencia de archivos
Propiedades: Facilidad de desarrollo, costo
Consideraciones: madurez, preparación empresarial, herramientas
Comentarios de Z ': Es fácil pasar por alto la humilde transferencia de archivos. Sin embargo, es una forma fácil y barata de transferir datos. Es particularmente útil para el procesamiento por lotes poco frecuente, donde no se necesitan capacidades en tiempo real.
Pensamientos finales
Elegir el estilo de diseño más adecuado para un proyecto de API suele ser un proceso complicado. Afortunadamente, Zdenek tiene un enfoque sencillo para encontrar el estilo que mejor se adapte a las necesidades de su organización. Sugiere que comience identificando las propiedades esenciales para su API, antes de compararlas con las propiedades inducidas por restricciones de ocho estilos de diseño populares. Zdenek también le aconseja llamar la atención sobre cualquier consideración específica de estilo que pueda influir en su decisión. ¡Y eso es todo!
0 Comentarios
Dejanos tu comentario para seguir mejorando!