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?
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.
Lee más sobre: ¿Qué es API 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:
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:
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:
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 te interesa aprender todo sobre GraphQL puedes comenzar ya mismo con el [Curso Básico de GraphQL])(https://platzi.com/cursos/graphql/), te aviso que solamente vemos la parte del backend.
Recuerda que REST tiene como base el protocolo HTTP, pues simplemente eso trae muchas ventajas frente a GraphQL:
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.
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.
La mayor fortaleza de GraphQL, las búsquedas con muchas relaciones, se puede convertir rápidamente en su mayor problema:
Supongamos que Platzi 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 Platzi, 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 Platzi 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. Si quieres reforzar tus conocimientos, evitar estos problemas o simplemente por el hecho de #NuncaPararDeAprender te invito a que mires el Curso de Consumo de API REST con JavaScript.
Muy bueno!, justamente estaba revisando el tema del Overfetching
Gracias por el aporte!
Paquetes como
apollo-link-retry
yapollo-cache-persist
permiten añadir cache a las respuestas del endpoint.También
dataloader
(desde el back-end), aunque es un poco viejo pero útil. Aunque ORM’s como Prisma2 y TypeORM ya añaden sus estrategías de cache…Un muy buen punto a tener en cuenta al diseñar servicios ya sea RESTful o con GraphQL.
Gracias por el dato.
Muchas Gracias, aclara mucho sobre API y que tecnologia usar para delimitarlas.
Excelente me aclaro algunas cositas 😉
Me interesa como simplificar la petición REST
Gracias por el dato,