Header Ads Widget

Ticker

6/recent/ticker-posts

¿Cómo se compara JSON: API con REST y GraphQL?



 Hay casi tantas opciones para herramientas API y estilos de diseño como API en sí mismas. La industria de API moderna tiene una variedad de especificaciones, marcos, paradigmas, arquitecturas, integraciones y extensiones que hacen que cada instancia de API sea única. Hoy veremos tres de esas opciones.

En una publicación anterior, exploramos los beneficios de usar JSON: API , una especificación para crear API en JSON. En este artículo, veremos cómo se compara la especificación con algunos otros estilos y especificaciones de diseño importantes en el mundo del diseño de API, a saber,  REST  y  GraphQL . Profundizaremos en lo que son cada una de estas cosas en términos generales, consideraremos qué las hace únicas y descubriremos cómo se relacionan entre sí.

¿Qué es JSON: API?

En pocas palabras, JSON: API es "una especificación para crear API en JSON", redactada originalmente por Yehuda Katz en mayo de 2013. Su objetivo original era crear un modelo de comunicación basado en interacciones definidas, en lugar de apoyarse en anuncios por aplicación ". código "hoc". JSON: API establece un estándar para la comunicación; expresa cómo se deben formatear las solicitudes al servidor, y luego cómo se debe formatear la respuesta al cliente. Su objetivo es optimizar las solicitudes HTTP reduciendo la cantidad de solicitudes necesarias y reduciendo el tamaño de los propios paquetes.

Lea también:  Los beneficios de usar la API JSON

Elementos únicos

JSON: API tiene muchas características interesantes. Los documentos compuestos permiten a los servidores responder a solicitudes con recursos relacionados, lo que imita gran parte de la funcionalidad de GraphQL sin crear un sistema demasiado complejo. Los clientes pueden aprovechar esto para recorrer el diseño de los recursos internos y obtener información más compleja.

Los clientes también pueden solicitar información muy específica utilizando conjuntos de campos dispersos , en los que el cliente solo solicita datos de un nombre de recurso específico y un conjunto específico de campos deseados. Esto hace que las llamadas sean mucho más eficientes que las que se ven en otros estándares de API relacionales. JSON: API también permite la opción de funciones: puede activar o desactivar cualquier cosa, siendo el cliente la principal fuente de aceptación o denegación.

Eso, combinado con la opcionalidad, constituye una poderosa limitación de lo que de otro modo podría ser una respuesta abultada. Además, JSON: API tiene un sistema de almacenamiento en caché eficaz porque todo utiliza el mismo esquema de acceso JSON: API cuando se trata de almacenar datos. En otras especificaciones, los datos se almacenan en diferentes ubicaciones, lo que puede hacer que el procesamiento y la respuesta sean más complicados y derrochadores.

¿Qué es REST?

REST , o Representational State Transfer, es un paradigma y una arquitectura diseñados por Roy Fielding, coautor de las especificaciones HTTP y URI. REST fue diseñado para proporcionar interoperabilidad entre recursos web mediante la definición de un conjunto uniforme de operaciones sin estado. Utiliza el conjunto estándar de GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS y TRACE para actuar sobre estos recursos, lo que hace que su uso y respuesta sean predecibles.

El uso de protocolos sin estado y operaciones estándar está destinado a proporcionar un rendimiento rápido , interacciones confiables (que se sabe que son exitosas antes de que el cliente realice una solicitud, ya que la verborrea de la solicitud es estándar) y extensibilidad a través de la estandarización. REST es actualmente el método de diseño más común para aplicaciones web.

Relacionado: ¿REST sigue siendo un estilo de API relevante?

Elementos únicos

REST se basa en la idea de que se actúe sobre los recursos separados utilizando una verborrea estándar. Debido a esto, cada solicitud solo responde con lo que solicitó. Esto lo convierte en un enfoque altamente eficiente, rápido y poderoso. Su naturaleza apátrida mejora casi todo lo relacionado con la experiencia del cliente.

REST es por su naturaleza algo confuso, solo brinda lo que se solicita expresamente. Esto puede agregar seguridad adicional , ya que es más difícil obtener una vista total de un recurso solicitado completo cuando obtiene datos devueltos limitados.

¿Qué es GraphQL?

GraphQL es un lenguaje de consulta de aplicaciones . Está diseñado principalmente para crear un formato predefinido, comprensible y estable para solicitudes. El sitio web oficial de GraphQL lo dice de manera más sucinta al decir "describe tus datos, pide lo que quieras, obtén resultados predecibles".

GraphQL fue diseñado internamente por Facebook en 2012 y se lanzó públicamente en 2015. Es una inversión de la relación típica cliente-servidor, lo que permite al cliente establecer específicamente la estructura de los datos y los datos en sí que deben devolverse desde el servidor. Esto dificulta el almacenamiento en caché, pero otorga un mayor control sobre la salida de datos y permite identificar, utilizar y ampliar relaciones de datos increíblemente complejas. GraphQL brinda información sobre los recursos relacionados, lo que le permite recorrer desde los primeros datos devueltos hasta más contenido de datos relacionados, formando un gráfico de datos relacionados y metarelaciones.

Relacionado: 5 beneficios potenciales de adoptar GraphQL

Elementos únicos

El principal atractivo de GraphQL es que el cliente solicita los datos y el formato en el que se entregan los datos. Esto significa que proporciona retornos de datos esperados mucho más estables y ofrece una mayor eficiencia al obtener solo los datos que se solicitan, no los que el servidor API asume que quieres.

La provisión de recursos relacionados también significa que puede realizar consultas más avanzadas y obtener todos esos datos de una sola vez, mientras que en otras soluciones como REST, necesitaría realizar series de llamadas de múltiples terminales enormemente complicadas para obtener todo. puede hacerlo en una sola solicitud GraphQL.

Relacionado: REST vs GraphQL: cómo las restricciones determinan el estilo

JSON: API comparada

Comparemos JSON: API con REST y GraphQL. Debemos señalar aquí que mucho de lo que surge aquí proviene del hecho de que REST es esencialmente un paradigma arquitectónico . GraphQL y JSON: API, por otro lado, son especificaciones . Estamos comparando ambos aquí porque REST se usa a menudo en forma simple, lo que lo convierte en un paradigma en su forma más básica y una especie de especificación en su iteración más popular.

Herramientas y comunidad

Cabe señalar que REST tiene una comunidad tan fuerte como un desarrollador podría pedir. REST ha existido durante muchos, muchos años en este momento. Como tal, existe una gran cantidad de herramientas, documentación, implementaciones, integraciones, extensiones y más que se pueden aprovechar para hacer que su oferta sea mucho mejor. JSON: API y GraphQL son, al menos en relación con REST, más nuevos en la escena y, como tales, no cuentan con una base comunitaria tan amplia o profunda.

Dicho esto, tanto GraphQL como JSON: API son compatibles con REST , y mientras que el diagrama de Venn de ofertas que son "REST y también GraphQL" no es 100% (y tampoco es el caso de JSON: API), las herramientas y la comunidad sigue siendo muy grande.

Esquemas, relaciones y respuestas

REST es un conjunto de verborrea estándar y, por lo tanto, tiene un esquema de recursos "esperado" asociado, pero no se establece ni se requiere nada específicamente. GraphQL funciona casi en su totalidad en el concepto de esquemas y, como tal, ha desarrollado este aspecto de sí mismo a alturas elevadas. Si bien JSON: API tiene esquemas básicos, son solo eso: básicos. Esto puede ser limitante para las API que necesitan esquemas y relaciones de recursos increíblemente complejas.

Esto conduce a diferencias en las relaciones y respuestas que probablemente sean la diferencia más marcada entre los tres. REST técnicamente puede proporcionar múltiples objetos de datos en una sola respuesta, pero esto no está estandarizado de ninguna manera en las diversas implementaciones que lo permitirían. JSON: API y GraphQL, por otro lado, tienen esquemas y formaciones de respuesta muy claras, lo que permite a los adoptados establecer relaciones de objetos de datos múltiples con mucha claridad. Además, REST no incorpora ningún dato relacionado de forma predeterminada en las respuestas, tanto JSON: API como GraphQL lo hacen.

Eficiencia

Con GraphQL y JSON: API, las solicitudes son muy eficientes. Dado que todo el contenido relacionado se sirve de una forma u otra con estas dos opciones (y con JSON: API, se denomina documentos compuestos), le queda un método sencillo para pasar del punto de entrada en el recurso a otro contenido. Con REST, esto requiere múltiples solicitudes, lo que convierte una solicitud única (aunque complicada) en un viaje de ida y vuelta de solicitudes de enfoque excesivamente singular. Si bien JSON: API y GraphQL manejan esto de manera diferente, el resultado final es en gran medida el mismo, por lo que no hay más discusión.

Facilidad de uso

REST es increíblemente sencillo de soportar. Dado que REST se basa en la verborrea y las metodologías HTTP estándar, casi cualquier cosa puede admitir REST, lo que requiere poca transformación de los recursos subyacentes. Esto también es cierto en gran medida con JSON: API, lo que lo convierte en un gran competidor para pasar de REST estándar sin el costo excesivo de pasar a una especificación más compleja.

GraphQL, por otro lado, puede requerir estructuras relacionales específicas y mecanismos de enclavamiento, lo que significa que, en algunos casos, es posible que toda su API deba reestructurarse en términos de lógica de recursos; esto puede llevar tiempo, dinero y esfuerzo que puede no justificar sí mismo al final.

Almacenamiento en caché

GraphQL no se presta fundamentalmente bien al almacenamiento en caché. Las respuestas GraphQL se crean específicamente para consultas específicas; como tales, ciertas constantes ciertamente se pueden almacenar en caché (como los números de versión), pero la naturaleza subyacente no es exactamente compatible con el almacenamiento en caché de respuestas totales. Ni REST ni JSON: API sufren de esto: el almacenamiento en caché está integrado en HTTP y, como tal, ambas tecnologías lo admiten de forma nativa.

Implicaciones de seguridad

Un gran beneficio para JSON: API y REST es que el nivel de seguridad suele ser más alto debido a su exposición más limitada de recursos. GraphQL puede exponer demasiada información con errores de configuración relativamente menores, restricciones necesarias omitidas o concesiones de respuesta demasiado liberales. Básicamente, GraphQL se trata de exponer tanta información relacionada como sea posible, y aunque esto puede ser un beneficio, también facilita mucho el dimensionamiento de la red de recursos.

Naturaleza fundamental

JSON: API es, en muchos sentidos, una solución mucho más básica que GraphQL y, por eso, ofrece gran parte de la gran funcionalidad de los sistemas similares a GraphQL sin la gran complejidad que pueden conllevar tales implementaciones. Esto viene con la advertencia, por supuesto, de que, en última instancia, está limitado por JSON: API de formas en las que es posible que no se encuentre limitado en GraphQL, lo que hace que la adopción de cualquiera de las dos sea una compensación entre funcionalidad y simplicidad. De cualquier manera, ambas son ligas más complejas que REST en su forma más básica (aunque algunos argumentarían que es casi seguro que si admite una API GraphQL o JSON: API, también es compatible con una API RESTful).

Conclusión

JSON: API es una especificación simple, potente y eficiente que hace mucho a pesar de lo sencillo que es. Esto lo coloca en el medio entre GraphQL y REST básico. Mientras que GraphQL le permite hacer casi cualquier cosa en términos de llamada y respuesta, lo que hace que su complejidad sea algo problemática a veces, y mientras que REST es simple, poderoso, pero en última instancia limitante en su forma más básica, JSON: API opera en algún lugar intermedio, proporcionando herramientas y respuestas poderosas y extensibles. Aunque nunca alcanzó las alturas del poder de GraphQL (y sus complejidades asociadas), sin embargo, es un fuerte competidor para ese tipo de funcionalidad.

Todo esto se reduce a lo que la API necesita específicamente. REST sigue siendo un gran paradigma y, como tal, no está realmente en peligro de desaparecer pronto. Dicho esto, se requiere una funcionalidad más compleja para muchos casos de uso empresarial, y GraphQL puede cumplir con eso con creces.

Si desea un sistema eficiente que sea más poderoso que la forma base limitada de REST, pero menos complejo que GraphQL y al mismo tiempo brinde un excelente servicio de contenido relacionado y un sólido sistema de almacenamiento en caché, JSON: API es una excelente opción.

¿Qué opinas sobre JSON: API? ¿Perdimos algún beneficio o inconveniente importante? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios