Header Ads Widget

Ticker

6/recent/ticker-posts

Una guía de expertos para elegir el estilo de API adecuado



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 .

Vea a Zdenek “Z” Nemec presente en la Cumbre de la Plataforma 2019:

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 .

Lea también: Cuándo usar Qué: REST, GraphQL, Webhooks, gRPC

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

Restricciones: cliente-servidor, sin estado, sistema en capas, interfaz uniforme

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

Restricciones: cliente-servidor, sin estado, interfaz uniforme

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

Restricciones: cliente-servidor, sin estado, almacenable en caché, sistema en capas, código a pedido, interfaz uniforme

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

Restricciones: cliente-servidor, sistema en capas

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

Restricciones: cliente-servidor

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

Restricciones: cliente-servidor

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!

Publicar un comentario

0 Comentarios