¿REST o GraphQL?

Distintas formas de desarrollar una API, cada una con sus ventajas y desventajas. GraphQL promete un gran futuro, pero ¿realmente ha dejado “obsoleto” a REST?

Breve historia de REST.

En la época de 1999 las API no tenían ningún estándar de diseño, todas se desarrollaban utilizando el protocolo SOAP, Simple Object Access Protocol, pero no te dejes engañar por la palabra Simple en su nombre, SOAP era complejo de desarrollar y de utilizar pues cada petición se hacía con XML.

En su tesis doctoral, Roy Fielding propone un conjunto de principios de arquitectura para desarrollar APIs teniendo como base el protocolo HTTP, de esta forma cualquier servidor podría comunicarse con cualquier otro en el mundo. Aquí nace REST, transferencia de estado representacional o representational state transfer en inglés.

Entendiendo REST

REST le agrega una capa muy delgada de complejidad y abstracción a HTTP. Mientras que HTTP es transferencia de archivos, REST se basa en la transferencia de recursos.

Las API RESTful son aquellas que están diseñadas con los conceptos de REST:

• Recursos: toda la información que proporcione la API debe ser un recurso.
• URI: los recursos en REST siempre se manipulan a partir de la URI, identificadores universales de recursos.
• Acción: todas las peticiones a tu API RESTful deben estar asociadas a uno de los verbos de HTTP.

Dentro de una API RESTful todo recurso que sea expuesto debe tener una URI única como identificador, los clientes que quieran acceder a estos recursos deberán hacerlo con el método HTTP correspondiente:

• GET para obtener/leer un recurso.
• POST para escribir/crear un nuevo recurso.
• PUT para modificar un recurso, debe mandar toda la información completa del recurso, no se puede sobrescribir partes puntuales del recurso.
• DELETE para borrar un recurso.

Para una API RESTful se debe planear primero, pensar en los casos de uso por adelantado, diseñar los recursos y los recursos de manera correspondiente.

REST es muy útil cuando:

• Las interacciones son simples.
• Los recursos de tu hardware son limitados.

Por otro lado, GraphQL es un lenguaje de consulta y un motor de ejecución creado originalmente en Facebook en 2012 para describir las capacidades y los requisitos de los modelos de datos para aplicaciones cliente-servidor. Actualmente el proyecto fue movido a la GraphQL Foundation, fundación que tiene el apoyo de la Linux Foundation.

Dentro de GraphQL debes describir los datos (schemas) que tu API va a exponer . Si bien la mayor ventaja de GraphQL es que el cliente puede elegir los datos que necesite, debes declarar la forma en la que los clientes van a acceder a estos datos, o sea, declarar los query y mutations.

Un API sencilla de GraphQL se vería de la siguiente forma:

// Ejemplo de un schema sobre personajes de Star Wars.
typeCharacter {
  name: String!
  appearsIn: [Episode!]!
}

// Definimos la Query donde, si solicitan un hero, nos pasan como parámetro el episodio en que aparece y podemos regresar toda la información de Character.
typeQuery {
  hero(episode: Episode): Character
}


// Definimos el schema principal. Una API GraphQL puede o no tener Mutation, pero sí debe tener Query.
schema {
  query: Query
}

Esto solamente es la definición en GraphQL, faltaría agregar la lógica para que pueda obtener la información de una base de datos, eso sería añadir los resolvers. 

Si GraphQL es sencillo, ¿Qué ventajas tiene REST?

Recuerda que REST tiene como base el protocolo HTTP, pues simplemente eso trae muchas ventajas frente a GraphQL:

Caché

GraphQL no tiene soporte para caché a diferencia de REST que usa mecanismos de HTTP nativos para el almacenamiento en caché.

Los desarrolladores deben buscar alternativas para brindar un servicio de caché, aunque Relay brinda cierta compatibilidad, todavía no es una tecnología madura como los mecanismos de HTTP.

Reporte de errores

Los servicios RESTful aprovechan los códigos de estado HTTP para diferentes errores que se pueden encontrar, desde el famoso 404 hasta 500. Esto hace que el monitoreo de las API sea muy fácil y sin esfuerzo para el desarrollador.

En GraphQL las respuestas siempre son 200 OK, debes programar que mande un mensaje de error y esperar que el cliente lo lea. En cambio en REST, gracias a HTTP, es posible saber que algo salió mal con las cabeceras de la petición.

Ataque a tus recursos

La mayor fortaleza de GraphQL, las búsquedas con muchas relaciones, se puede convertir rápidamente en su mayor problema:

Supongamos que praysoft tiene una API en GraphQL y queremos realizar una petición que me regrese el nombre de los amigos de los amigos de Juan que estudian en praysoft, podría verse algo como lo siguiente:

{
  student(name: “Juan”) {
    friends {
      friends {
        name
      }
    }
  }
}

Es una query compleja, dentro de REST tendríamos que hacer muchas peticiones HTTP, pero ¿qué pasa si alguien quiere tirar praysoft haciendo muchas peticiones todavía más complejas?

{
  student(name: “Juan”) {
    friends {
      friends {
        friends {
          friends {
            friends {
             friends {
               name
             }
           }
         }
        }
      }
    }
  }
}

Pues bueno, como desarrollador de una API GraphQL debes programar un límite para la profundidad de las peticiones, de otra forma tu API podría sufrir severos ataques.

---

GraphQL es el futuro, sí, pero le falta mucho para llegar a la madurez que tiene REST. Además, dentro de las empresas es muy probable que sigan usando REST por un largo tiempo, pues el costo de migrar a GraphQL puede ser caro y a veces hasta innecesario, si tienes una API con recursos muy relacionados entonces sí te conviene GraphQL.

Problemas como el overfetching o underfetching suelen darse porque una API REST no está bien diseñada.