"REST Vs GraphQL" ¿es una comparación correcta?


7

Vi en muchos sitios que comparan REST con GraphQL. después de investigar esta preocupación (en realidad, mi preocupación) de que, "¿es una comparación correcta?", estoy más confundido. Dado que REST tiene una definición diferente frente a GraphQL, esta pregunta me preocupa, por qué podremos comparar dos conceptos diferentes juntos.

En realidad, me parece que la comparación es algo como esto:

IDE Vs Compilador! o BMW x6 Vs ISO 18541-5 (vehículos de carretera)

de wiki:

Definición de descanso:

Representational State Transfer (REST) es un estilo de arquitectura de software que define un conjunto de restricciones que se utilizarán para crear servicios web.

Definición GraphQl:

GraphQL es un lenguaje de consulta y manipulación de datos de código abierto para API, y un tiempo de ejecución para completar consultas con datos existentes.

por favor aclara mi mente con tus respuestas. Gracias


La página de inicio de GraphQL ya describe las diferencias bastante bien. ¿Sobre qué necesita específicamente brillo adicional?
Robert Harvey

1
Ambas cosas no se pueden comparar a menos que elija simplificar demasiado lo que es REST y reducirlo a simples CRUDOS web a través de HTTP, lo que definitivamente no es. Es como comparar SOA con SQL.
Laiv

¿Pueden agregar algunos ejemplos de tales artículos / sitios? Nos ayudaría conocer las fuentes de esta pregunta :)
CorwinCZ

Respuestas:


6

REST es un estilo arquitectónico, desarrollado en paralelo con la red mundial en la década de 1990.

La World Wide Web es una aplicación de referencia para el estilo arquitectónico REST (con algunas desviaciones ).

HTTP es un protocolo de aplicación para transferir documentos a través de una red.

GraphQL es un lenguaje de consulta y un motor de ejecución .

Tienes razón en que comparar directamente REST y GraphQL es un desastre. Sin embargo, lo que puede hacer es observar cuidadosamente los tipos de problemas que intentaban resolver.

Al aplicar el principio de generalidad de ingeniería de software a la interfaz del componente, se simplifica la arquitectura general del sistema y se mejora la visibilidad de las interacciones. Las implementaciones están desacopladas de los servicios que brindan, lo que fomenta la evolución independiente. Sin embargo, la desventaja es que una interfaz uniforme degrada la eficiencia, ya que la información se transfiere de forma estandarizada en lugar de una que sea específica para las necesidades de una aplicación. La interfaz REST está diseñada para ser eficiente para la transferencia de datos hipermedia de gran tamaño, optimizando para el caso común de la Web, pero resultando en una interfaz que no es óptima para otras formas de interacción arquitectónica. Fielding, 2000

En REST, el almacenamiento en caché es un gran problema, y ​​la especificación HTTP actual tiene un RFC completo dedicado a la semántica de almacenamiento en caché; pero la gente que usa GraphQL aparentemente ha decidido que el almacenamiento en caché no es significativo para su problema.

Lo mejor que puedo decir es que GraphQL está haciendo muchas de las mismas elecciones de acoplamiento que SOAP . Eso no es correcto o incorrecto, solo un equilibrio diferente de las compensaciones.


4

No, esta comparación no es válida.

Como ha dicho, GraphQL y REST son cosas diferentes, por lo que es como comparar manzanas y naranjas.

Esa es una vista / perspectiva de este problema. El segundo es todo lo contrario: las comparaciones GraphQL / REST son válidas y muy útiles .

Para entender esta segunda visión, debemos hacernos esta pregunta:

¿Cuáles son las formas posibles de entregar mis datos a los clientes? ¿Cuál debo elegir?

La respuesta a la primera pregunta contiene REST y GraphQL (con muchas otras formas). Ambos son útiles para entregar datos a los clientes (leer, crear API). La segunda pregunta es en realidad la que respalda todas las comparaciones que has leído.

Comparar formas diferentes de entregar datos es válido y necesario. Desde este punto de vista, no importa que la naturaleza de las cosas comparadas sea diferente. Ambos pueden hacer el trabajo, así que debes compararlos.

Es como comparar el sabor de las manzanas y las naranjas: puedes hacerlo.

Personalmente estoy haciendo esta comparación todo el tiempo. Muy útil para enseñar a otros colegas diferentes formas de resolver problemas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.