Header Ads Widget

Ticker

6/recent/ticker-posts

GraphQL vs REST: la preferencia del consumidor

 


Al comparar los estilos de diseño de API, es fundamental otorgar la máxima importancia a las necesidades de los consumidores. Según el informe del estado de API de Smartbear 2019 , la usabilidad, el rendimiento y la documentación son los factores más críticos para los consumidores que utilizan una API. Por lo tanto, el estilo de diseño ideal debe sobresalir en estas tres áreas. En este artículo, comparamos dos rivales de diseño, GraphQL y REST , en estas tres categorías, extrayendo información de ejemplos cotidianos.

Basamos esta publicación en una charla impartida por James Neate de Capgemini UK en la Cumbre de la Plataforma Nórdica de APIs 2019. Míralo aquí:

Usabilidad

Cuando se trata de usabilidad , REST y GraphQL son dos bestias completamente diferentes, especialmente en lo que respecta a la predictibilidad. Con REST, por ejemplo, el comportamiento de la API varía enormemente según el método URI y HTTP elegido, lo que dificulta que los consumidores sepan qué esperar con un nuevo punto final. Por otro lado, GraphQL se basa en operaciones explícitas (consultas y mutaciones) que ofrecen resultados predecibles.

“Con GraphQL, debido a que estás definiendo explícitamente en la carga útil lo que estás haciendo, entonces estás diciendo que estoy haciendo una consulta o haciendo una mutación, es extremadamente claro para el consumidor lo que está sucediendo con la API. "

El control de versiones es otro aspecto de la usabilidad que difiere entre los dos estilos de diseño. REST no tiene reglas claras para el control de versiones, lo que significa que cada proveedor usa su propio enfoque (a pesar de la creencia del autor Roy Fielding de que las API no deben tener control de versiones ). Por el contrario, GraphQL tiene un enfoque sencillo y establecido para el control de versiones: no versión .

En ambos aspectos, previsibilidad y control de versiones, la simplicidad de GraphQL contribuye en gran medida a la usabilidad. Por otro lado, la flexibilidad de REST es principalmente una característica neutra, que puede impactar positiva o negativamente la usabilidad dependiendo del diseño de la API individual.

Lea también: Cómo hacer que GraphQL funcione para usted

Actuación

Para comparar las diferencias de rendimiento entre REST y GraphQL, considere una interfaz de usuario que recupera información sobre los países que selecciona en un mapa mundial por medio de una API. Con una API REST, la selección de tres países daría como resultado tres llamadas API, una para cada país. Por otro lado, solo se necesitaría una sola solicitud a una API GraphQL para acceder a la misma información.

“A menudo, GraphQL se presenta como una nueva forma revolucionaria de pensar sobre las API. En lugar de trabajar con extremos rígidos definidos por el servidor, puede enviar consultas para obtener exactamente los datos que busca en una sola solicitud ". Sashko Stubailo, Apollo GraphQL

Sin embargo, si una red de entrega de contenido, un caché web o un proxy inverso se encontraba frente a la API REST, probablemente podría devolver respuestas en caché para las tres llamadas más rápido de lo que la API GraphQL podría devolver su única respuesta. Esto se debe a que una llamada GraphQL tiene que volver a la fuente de información para recuperar exactamente lo que pide el consumidor. De hecho, existen algunas opciones de almacenamiento en caché para GraphQL, pero no a nivel HTTP (como en el caso de REST).

“El almacenamiento en caché está integrado en la especificación HTTP que las API RESTful pueden aprovechar. La semántica GET vs POST relacionada con el almacenamiento en caché está bien definida, lo que permite que sigan las cachés del navegador, los proxies intermedios y los marcos del servidor ". Derric Gilling, Moesif

El rendimiento es una categoría donde la comparación de REST y GraphQL es mucho menos clara. Aunque GraphQL gana en la cantidad de llamadas a API necesarias para una aplicación promedio, REST gana en la amplitud de sus opciones de almacenamiento en caché.

Documentación

La madurez de REST ha dado lugar a una gran cantidad de opciones para la documentación automatizada . Desde OpenAPI hasta API Blueprint , y todo lo demás, existe una amplia gama de estándares de especificación y documentación , todos mostrando información de formas ligeramente diferentes. Por otro lado, casi todas las API de GraphQL públicas se documentan con una sola herramienta: GraphiQL .

Desafortunadamente, la documentación automatizada para ambos estilos de diseño sigue siendo insuficiente. Si bien puede ofrecer la información necesaria sobre puntos finales y objetos, rara vez maneja temas como autenticación , limitación de velocidad o incluso implicaciones financieras. En cualquier caso, la madurez de REST es un arma de doble filo, ya que las herramientas enriquecidas ofrecen variedad funcional a expensas de una experiencia consistente; GraphQL, por supuesto, enfrenta el problema opuesto.

Un tema común

A pesar de la estrecha rivalidad entre los dos estilos de diseño, tanto GraphQL como REST logran abordar los tres rasgos más importantes de una API: usabilidad, rendimiento y documentación . En términos de usabilidad y documentación, un tema común es que GraphQL ofrece simplicidad y previsibilidad, mientras que REST cuenta con una mayor flexibilidad. (Irónicamente, esto es todo lo contrario de cómo se caracteriza el comportamiento del punto final en cada uno de los dos estilos). Con respecto al desempeño de los dos estilos, un tema polémico, parece que todavía hay algo que decir sobre REST y su entusiasta uso de HTTP: almacenamiento en caché .

Lea también: REST vs GraphQL: cómo las restricciones determinan el estilo

Elegir entre GraphQL y REST

En última instancia, la capacidad de una API para sobresalir en estas tres áreas depende menos de si está diseñada con REST o GraphQL (o cualquier otro estilo de diseño) y más de cómo está diseñada. Dicho esto, vale la pena tener en cuenta que cada estilo de diseño tiene sus propias peculiaridades y características, que pueden adaptarse bien a las consideraciones de diseño específicas de una API.

Por ejemplo, una característica destacada de GraphQL es su funcionalidad de consulta avanzada. Con REST, las consultas básicas no son un problema, pero a medida que aumenta el número y la complejidad de los parámetros de consulta, pueden surgir problemas. Como resultado, GraphQL podría ofrecer un mejor servicio a las API que garantizan consultas extensas.

Por otro lado, REST tiene una toma significativamente más fácil de cargar archivos. Dado que aprovecha al máximo HTTP, los archivos más pequeños se pueden cargar directamente desde una máquina local o URL. Por otro lado, GraphQL requiere un servicio de carga independiente incluso para los archivos más pequeños. Por lo tanto, la necesidad de cargar archivos de forma rápida y sencilla, como imágenes, puede convertir a REST en la opción preferida.

En conclusión, el diseñador de API habilidoso debe reconocer cómo los desarrolladores utilizarán una API. Esto no solo informará qué estilo de diseño se adapta mejor a los requisitos de la API, sino que también dará como resultado una API excelente independientemente del estilo de diseño que se elija.

Publicar un comentario

0 Comentarios