Header Ads Widget

Ticker

6/recent/ticker-posts

4 ajustes de diseño para mejorar las operaciones de API

 

Anteriormente discutimos las mejores prácticas cuando se trata de diseñar una API con experiencia de desarrollador de calidad. Pero, ¿cuáles serán las repercusiones operativas a largo plazo para los movimientos de diseño que hacemos ahora?

Por ejemplo, si las URL se diseñan sin metadatos para describir acciones, más adelante, los propietarios de productos tendrán dificultades para mirar registros ininteligibles. O, si los microservicios no están organizados correctamente, corre el riesgo de que los tiempos de carga sean prolongados al poner en cola varias llamadas de API en un entorno móvil. Estas son solo dos de las muchas consecuencias operativas que muchos propietarios de API pasan por alto al diseñar sus API.

Hoy, consideraremos algunos métodos para hacer que las interfaces de programación de aplicaciones web sean más eficientes operativamente y que respondan a la forma en que los clientes las consumirán. Dirigido por el veterano de las API nórdicas Jason Harmon, cubriremos los anti-patrones operativos más comunes que podrían romper una API. Ofreceremos formas de remediar estas situaciones de diseño deficiente, que si no se abordan, podrían causar algunas migrañas graves más adelante en el ciclo de vida de la API.

Errores operativos comunes de la API a tener en cuenta

Consideremos cuatro anti-patrones que se encuentran en la naturaleza con demasiada frecuencia: desde problemas simples, pero a menudo pasados ​​por alto, como usar el método HTTP apropiado, hasta errores de composición más complejos.

"Hasta cierto punto, la forma en que diseñas tu API puede prepararte para el fracaso".


En nuestra última Platform Summit, Jason Harmon habló sobre los antipatrones de diseño de API operativas

1: HTTP GET en lugar de POST

Los proveedores de API comúnmente implementan una GETllamada HTTP donde POSTdebería haberse usado en su lugar. Un recordatorio para usar el método HTTP correcto es, con mucho, el consejo más básico aquí, pero sorprendentemente, es un error común que puede causar un daño importante.

Harmon relató una historia de su experiencia en Typeform, donde un pequeño subconjunto de usuarios en los navegadores web estaban presionando el botón "Atrás", haciendo que sus sesiones perdieran todos los datos. Al cambiar el tipo de llamada de GETPOST, Typeform pudo resolver rápidamente su problema de almacenamiento en caché, ya que la RFC de HTTP establece POSTque nada puede almacenar en caché.

La lección aquí es tener cuidado con las llamadas en caché de los navegadores o proxies. Si encuentra un comportamiento inesperado, Harmon recomienda primero "buscar el GETs ... usar en su POSTlugar es una solución fácil". Si está atrapado en una situación con problemas de caché erráticos, agrega que agregar una cadena de consulta adicional con un cachebuster generado aleatoriamente a la GETllamada (es decir ?cache_buster=[random]) podría resolver un problema recurrente.

2: Permitir a los clientes sondear constantemente las API

Muchos proveedores de API deberían reconsiderar cómo permiten que los clientes actualicen los datos. Con demasiada frecuencia, el cliente configura un sondeo constante en los puntos finales de la API. Cuando se trata de un gran conjunto de datos y las consultas se realizan de forma continua, como cada 30 segundos, la cantidad de llamadas puede sumarse. Los grandes volúmenes de llamadas a un servidor de AWS también pueden resultar costosos.

Typeform no es inmune al problema del sondeo de API. Los usuarios finales de Typeform quieren saber si hay datos actualizados en su formulario y, por lo tanto, configuran un servicio de sondeo constante para ver si los datos se han actualizado. Dado que Typeform se encuentra entre las aplicaciones compatibles con Zapier, lo que significa que los usuarios pueden crear "zaps" personalizables que se relacionan con las funcionalidades de Typeform, la cantidad de servicios que continuamente solicitan nuevos datos se dispara.

Para evitar el sondeo constante, Harmon le recomienda crear y lanzar webhooks para su servicio y convencer a sus consumidores de que los utilicen. Pero primero, averigüe cuál es la tasa de cambio de sus datos . Por ejemplo, la tasa promedio de cambio para Typeforms suele ser de 1 a 2 semanas. Identificar un patrón para la tasa de cambio en sus datos puede ayudarlo a diseñar sus webhooks para que sean lo más ajustados posible.

Harmon reconoce un inconveniente en este enfoque: recomienda seguir utilizando una API de sondeo junto con la carga útil del webhook para realizar comprobaciones esporádicas del sistema y realizar descargas grandes.

3: la jerarquía rígida en microservicios provoca latencia

Últimamente, muchos proveedores de SaaS han realizado la transición al estilo arquitectónico de microservicios . Los microservicios son componentes ajustados y bien delimitados dedicados a procesar una funcionalidad especializada. Esto es excelente para la segmentación estructural, pero si la comunicación de microservicio no está bien orquestada , la solicitud de datos puede causar una latencia grave.

"Cree sus microservicios para que se externalicen desde cero"

Se implementó un BFF para resolver problemas de diseño de microservicios tanto en Paypal como en Typeform. Al disminuir los paquetes JSON, un BFF puede reducir el procesamiento de JavaScript. Sam Newman describe el uso de un BFF para cada tipo de interfaz de cliente.

El problema con los microservicios es que un cliente que solicita una gran cantidad de funciones podría terminar enviando docenas de llamadas separadas, lo que generaría una carga masiva de consultas . Esto es especialmente problemático en entornos móviles, donde las llamadas deben ponerse en cola en serie en lugar de ejecutarse en paralelo entre sí. Para algunos entornos, este proceso es simplemente demasiado lento.

Según Harmon, la solución está en una BFF . No, no es un mejor amigo para siempre, sino un Backend-for-Frontend que actúa como una corrección para ayudar a componer microservicios.

Un BFF es una capa ligera que actúa como una API de orquestación. Podría construirse como un servicio Node.js, o como lo consideren los desarrolladores internos. El objetivo de dicha corrección es que, con una llamada, el cliente reciba todos los recursos empaquetados de la forma que el cliente desee. De esa manera, para ponerlo en palabras de Harmon:

"No están pegando un modelo en el navegador, el modelo ya se les entregó de la forma en que lo querían en primer lugar".

Permitir que los clientes llamen a un microservicio directamente sin ninguna capa de composición es un diseño deficiente, ya que no considera los casos de uso y las limitaciones del cliente. La construcción de una capa BFF es una posible solución, pero debe tenerse en cuenta que GraphQL también es otra solución potencial.

Lea también: API asincrónicas en microservicios coreografiados

4: acciones genéricas

Cuando diseñamos URL, Harmon nos recuerda que es importante detallar las acciones . Recomienda anotar las transiciones de estado dentro de la URL y transmitir descripciones breves como metadatos. Si no describe las transiciones de estado fuera de los verbos típicos de CRUD, corre el riesgo de tener registros muy genéricos e ilegibles.

Este problema a menudo se denomina tunelización de protocolos ; con nombres de URL genéricos, a menudo se pierde la perspectiva y, luego, cuando se interrumpe una acción, es difícil localizar las llamadas afectadas y analizar las tendencias. Si diseñamos las URL como frases genéricas que no nos dicen nada sobre toda la historia, el diagnóstico de errores será difícil.

"Las URL son un componente clave en la forma en que opera la API"

Harmon señala que esto es especialmente importante para los propietarios de productos que utilizan herramientas como la pila ELK para visualizar las fuentes de datos y determinar los conocimientos. Al diseñar URL, la visibilidad es una ventaja, así que considere un buen método para identificar estas URL con un esquema de nomenclatura, junto con los metadatos de las acciones que se están tomando.

/resource/:id/generic-name + {action:process}

Mantras armoniosos para vivir

Hemos cubierto mucho terreno con algunos problemas específicos para evitar. Para obtener consejos de diseño más genéricos, el sabio Harmon proporciona algunos mantras para diseñar mediante:

  • Primero use los casos, luego diseñe : asegúrese de que sus métodos HTTP estén correctamente asignados y que el comportamiento del usuario no afecte negativamente el resultado.
  • El diseño puede influir en el rendimiento : ponga fin a las encuestas . Más bien, diseñe con webhooks de suscripción e insista en que los clientes los usen.
  • La estructura es buena, pero esté preparado para difuminar esas líneas : aunque la arquitectura de microservicios se trata de una división separada, tener una estructura demasiado rígida puede resultar en "clientes insatisfechos y un rendimiento deficiente".
  • El diseño puede apagar incendios : tener un enfoque DevOps para diseñar desde el principio puede apagar incendios a largo plazo. Intente hacer que el rendimiento sea más visible.
  • Se trata de los registros : en última instancia, sus registros son la transcripción de lo que los clientes están haciendo realmente. Considere cómo puede hacer que este rendimiento sea más inteligible mediante la elaboración de URL y metadatos que ayudarán al análisis de métricas y harán felices a los propietarios de productos.

La experiencia del desarrollador es el pilar de la mayoría de las discusiones sobre el diseño de API, pero no debemos ignorar cómo los movimientos de diseño también afectarán las operaciones de la API Como señala Harmon:

"El diseño de API no es solo discusiones fantásticas sobre usabilidad y muchas emociones esponjosas sobre los desarrolladores ... La experiencia del desarrollador es realmente solo la primera capa".

Siguiendo estas pautas, podemos mejorar áreas específicas para ayudar al diseño a una escala de décadas, ya que la eficiencia operativa está íntimamente relacionada con la longevidad de la plataforma . Al planificar las mejoras operativas ahora, podemos "diseñar de una manera que escriba oraciones, para contar una historia más grande más adelante".

Vea también al veterano de las API nórdicas Jason Harmon presentar sus consejos sobre cómo escalar el diseño de API en la Cumbre de 2014

Publicar un comentario

0 Comentarios