Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cuán granular debe diseñar API?

 


Una de las muchas cosas a tener en cuenta al crear una gran API es la granularidad . Para los desarrolladores más experimentados, el concepto de granularidad es un hecho, pero puede ser un concepto confuso para los programadores nuevos en el desarrollo de API.

En este breve artículo, le presentaremos el concepto de granularidad de API con una analogía útil y muy sabrosa, comparando los pros y los contras de las API de grano fino y grueso a medida que avanzamos. Para terminar, veremos cómo puede determinar el nivel correcto de granularidad para sus propias API.

Introducción a la granularidad

Lo primero es lo primero: ¿qué es la granularidad ?

La granularidad es la medida en que una API divide la información entre recursos individuales. En realidad, no se refiere a cuánta información expone una API, sino a cuántos recursos se distribuye esa información. Con una API detallada , es posible que un consumidor tenga que realizar varias solicitudes muy específicas a diferentes puntos finales para obtener la misma cantidad de información que obtendría de una sola llamada a una API general .

Para solidificar realmente esa idea, veamos un ejemplo. Imagine que está construyendo una plataforma de redes sociales y desea exponer información básica del usuario, como nombres de usuarios, pasatiempos y amigos, mediante una API. ¿Cómo implementaría esto?

Un enfoque es permitir que los desarrolladores obtengan todos los datos del usuario en el /user/{userID}punto final, lo que puede devolver una respuesta similar a esta:

{
"name" : "Thomas Bush" ,
"hobbies" : [ "cooking" , "swimming" ] ,
"friends" : [ "2" , "4" , "5" ]
}

Con este enfoque, los desarrolladores realizan una sola solicitud, pero obtienen toda la información del usuario que necesitan (el nombre del usuario, pasatiempos y amigos) en una sola respuesta. Este sería un recurso de grano grueso.

Una alternativa es la información del usuario división a través de distintos /name/{userID}/hobbies/{userID}/friends/{userID}los puntos finales. Una respuesta de ejemplo del /hobbies/{userID}punto final sería:

{
"hobbies" : [ "cooking" , "swimming" ]
}

Con este segundo enfoque, el desarrollador tiene que hacer tres peticiones separadas - Al /name/{userID}/hobbies/{userID}/friends/{userID}los puntos finales - sólo para obtener la misma información que a partir de una sola llamada a la /user/{userID}que nos presentamos por primera vez. Este, entonces, sería un recurso detallado.

La pregunta es: ¿qué es mejor? ¿Una API con recursos específicos o una API con recursos específicos?

De grano fino vs de grano grueso

Existe un caso para la granularidad fina y gruesa en términos de rendimiento de API. Con recursos de grano grueso , los desarrolladores necesitan realizar menos llamadas para obtener la misma cantidad de información, lo que reduce la latencia acumulativa y acelera las implementaciones. Sin embargo, con recursos de grano grueso, corre el riesgo de brindar a los consumidores más información de la que necesitan y, por lo tanto, utilizar cantidades excesivas de ancho de banda .

Lo contrario es cierto para los recursos de grano fino . Por un lado, no les está dando a los consumidores más información de la que necesitan ( ahorrando así ancho de banda ), pero por otro lado, los desarrolladores ahora necesitan hacer más llamadas para obtener la misma cantidad de información (lo que ralentiza las implementaciones del cliente).

Cuando se trata de rendimiento , tendrá que hacer un compromiso entre granularidad fina y gruesa. La forma en que realice esa compensación dependerá de cómo se utilice su API. Por ejemplo, si su API sirve principalmente a usuarios móviles, es posible que desee inclinarse hacia recursos más finos, lo que minimizaría el uso de ancho de banda. Por otro lado, si su API proporciona datos del mercado financiero en tiempo real, es posible que desee inclinarse hacia recursos más generales, lo que reduciría los efectos de la latencia.

La Fábrica de Pizza

Sin embargo, no es solo una cuestión de rendimiento. La granularidad puede tener un gran impacto en la forma en que los desarrolladores interactúan con su API, y aquí es donde quiero presentar una explicación fantástica, basada en pizza, de la granularidad de API que vi en LinkedIn .

La analogía es la siguiente: suponga que proporciona ingredientes de pizza a una variedad de clientes: pizzerías, chefs aficionados y desarrolladores hambrientos. Si tuviera que brindar un servicio de grano fino, podría ofrecer harina, queso, hierbas, varios ingredientes de salsa y una selección de aderezos. Esto sin duda atraería a las pizzerías como clientes.

Si desea adoptar un enfoque un poco más tosco, puede ofrecer masa de pizza prefabricada, una salsa de tomate lista y algunos aderezos. Por un lado, esto significa menos libertad para sus clientes, ya que no pueden hacer la masa o la fuente exactamente como quieren, pero también significa menos complejidad. Como resultado, las pizzerías podrían estar menos interesadas, ¡pero los chefs aficionados estarán más interesados!

Sin embargo, los desarrolladores hambrientos no querrán ninguno de esos. ¡Querrán una pizza recién cocinada que esté lista para consumir nada más sacarla de la caja! Pero, por supuesto, si solo vende pizzas cocidas, ni las pizzerías ni los chefs aficionados estarán interesados.

¿Vendes los ingredientes de la pizza o la pizza entera? La granularidad de la API afectará a quién es su desarrollador objetivo y viceversa.

Creo que esta analogía hace un gran trabajo al resaltar dos ideas cruciales:

  1. Existe una estrecha relación entre la granularidad y el contexto empresarial
  2. Una granularidad más gruesa tiende a significar menos libertad, pero también menos complejidad (razón por la cual los recursos de grano grueso deben diseñarse con especial preocupación por cómo se utilizarán en última instancia)

En particular, es esa primera idea la que es realmente importante tener en cuenta al encontrar la granularidad adecuada para sus API: la correlación entre la granularidad y el contexto empresarial . Puede hacer que sea mucho más fácil trabajar con una API asegurándose de que exponga los datos (y la funcionalidad) de manera correspondiente a algún contexto práctico.

Aquí es donde es realmente importante saber quién está usando su API y para qué, para que pueda elegir el nivel correcto de granularidad para ellos y para asegurarse de que los recursos de grano más grueso realmente correspondan a sus necesidades.

Pensamientos finales

La idea de granularidad no es tan difícil como parece. Es una cuestión de si expondrá recursos individuales y detallados por separado o los combinará para crear un recurso único y más completo. La elección del nivel correcto de granularidad siempre será una compensación de rendimiento, pero es la relación entre la granularidad y el contexto empresarial lo que nos hace inclinarnos hacia el lado burdo.

Publicar un comentario

0 Comentarios