Antes de tudo, isso não é realmente uma disputa, analisando o vídeo do Augusto Galego no Twitter sobre o mesmo assunto, estou separando as ideias que de fato, fazem sentido pra mim referente a uma análise de prós e contras.
Ultimamente ando sim, usando muito RestAPI, mais do que já usei GraphQL na vida. Acredito que a única vez em que usei, foi durante minha experiência na Stone para fazer comunicação com bot e tudo mais, então, é um assunto que de fato, eu preciso me aprofundar, ainda mais que quero atingir a plenitude como desenvolvedor fullstack, porém, não é algo que eu sinta firmeza ainda.
Você desenvolvedor, tem todo o direito de questionar meus prós e contras, e tirar dúvidas, se assim for, até por quê eu não sou nenhum especialista em GraphQL e utilizo bem mais o método de RestAPI no dia a dia. Então, vamos lá.
RestAPI (Representational State Transfer API) é uma abordagem arquitetural para criar serviços web, fazer a comunicação entre back-end e front-end para consumir dados. Ele é baseado no protocolo HTTP e utiliza os verbos HTTP (GET, POST, PUT, DELETE) para manipular recursos e representar o estado desses recursos por meio de representações como JSON ou XML.
Pontos Positivos do RestAPI:
Simplicidade: O RestAPI segue princípios simples e bem estabelecidos, como a utilização de URIs (Uniform Resource Identifiers) para identificar recursos e os verbos HTTP para manipular esses recursos. Isso torna a API fácil de entender e implementar.
Suporte Universal: RestAPIs são amplamente suportadas e podem ser acessadas por qualquer cliente que seja capaz de fazer requisições HTTP. Isso significa que a API pode ser consumida por diferentes tipos de aplicativos, como aplicativos web, aplicativos móveis e até mesmo por outros serviços web.
Escalabilidade: RestAPIs são altamente escaláveis, permitindo o crescimento da base de usuários e a expansão dos recursos de forma eficiente. Como o RestAPI é baseado no protocolo HTTP, ele pode ser facilmente distribuído e escalado horizontalmente para atender a um grande número de solicitações concorrentes.
Cache: RestAPIs oferecem suporte a recursos de cache embutidos no protocolo HTTP, como a utilização adequada dos cabeçalhos de cache. Isso permite que as respostas sejam armazenadas em cache em diferentes camadas, melhorando o desempenho e a eficiência da API.
Pontos Negativos do RestAPI:
Overfetching e Underfetching: Em APIs Restful tradicionais, é comum ocorrer overfetching (quando o cliente recebe mais dados do que o necessário) ou underfetching (quando o cliente precisa fazer várias chamadas para obter todos os dados necessários). Isso pode levar a um aumento no tráfego da rede e no tempo de resposta.
Rigidez: APIs Restful podem se tornar rígidas e difíceis de evoluir com o tempo. Isso ocorre porque qualquer mudança nos recursos ou na estrutura da API pode afetar a compatibilidade com versões anteriores e exigir atualizações nos clientes existentes.
Documentação: APIs Restful geralmente exigem uma documentação detalhada para que os clientes possam entender corretamente os recursos disponíveis, os formatos de dados aceitos e como usar corretamente os verbos HTTP. A falta de uma documentação clara e atualizada pode dificultar a adoção e o uso da API. Nesse caso, recomendo o uso do Swagger.
Falta de Padronização: Embora RestAPIs sigam princípios e diretrizes bem estabelecidos, a falta de uma padronização rigorosa pode levar a diferentes implementações e interpretações. Isso pode dificultar a interoperabilidade entre diferentes APIs e exigir esforço adicional para integrar e consumir diferentes serviços.
E o que é o RestFul?
API Rest e API Restful são termos frequentemente usados de forma intercambiável, mas há uma diferença sutil entre eles.
API Rest (ou simplesmente Rest) é uma abordagem arquitetural que define um conjunto de princípios e diretrizes para o design de serviços web. Esses princípios incluem o uso adequado dos verbos HTTP (GET, POST, PUT, DELETE) para manipular recursos, a utilização de URIs (Uniform Resource Identifiers) para identificar recursos e a representação do estado desses recursos por meio de formatos como JSON ou XML.
Por outro lado, API Restful (ou Restful API) refere-se a uma API que adere aos princípios e diretrizes do Rest de forma estrita. Isso significa que uma API Restful segue rigorosamente o protocolo HTTP e todas as suas características, como a utilização correta dos verbos HTTP, o uso de códigos de status adequados e a utilização de URIs significativas e amigáveis.
Em resumo, uma API Restful é uma implementação específica do Rest, seguindo estritamente seus princípios e diretrizes. Enquanto uma API Rest pode aderir aos princípios do Rest, mas não necessariamente de forma estrita.
Em termos práticos, a diferença entre API Rest e API Restful é sutil e muitas vezes negligenciada. Ambos os termos são usados para descrever APIs que seguem o estilo Rest, mas a terminologia "Restful" é frequentemente usada para enfatizar que a API adere rigorosamente aos princípios e diretrizes do Rest.
E quanto ao GraphQL?
GraphQL é uma linguagem de consulta para APIs e um tempo de execução para executar essas consultas com seus dados existentes. É uma alternativa à abordagem tradicional de RESTful APIs, fornecendo uma maneira mais eficiente e flexível de buscar e manipular dados.
Pontos Positivos do GraphQL:
Eficiência: Uma das principais vantagens do GraphQL é que ele permite que o cliente especifique exatamente os dados necessários, evitando assim o problema de overfetching ou underfetching que ocorre com frequência em APIs RESTful. Com GraphQL, o cliente pode buscar apenas os campos necessários para sua aplicação, reduzindo a largura de banda e o tempo de resposta.
Flexibilidade: Com GraphQL, o cliente tem controle total sobre os dados que deseja buscar. Ele pode especificar os campos e relacionamentos necessários em uma única consulta e obter todas as informações em uma única chamada. Isso reduz a necessidade de várias chamadas para diferentes endpoints e simplifica a lógica do cliente.
Evolução de API: GraphQL permite a evolução incremental de uma API sem quebrar a compatibilidade com versões anteriores. Os clientes podem adicionar novos campos às suas consultas sem afetar os aplicativos existentes. Isso proporciona uma experiência de desenvolvimento mais flexível e facilita a adoção de novos recursos.
Ferramentas e Ecossistema: GraphQL possui um ecossistema robusto de ferramentas e bibliotecas de suporte. Existem muitas ferramentas disponíveis para ajudar no desenvolvimento, como o GraphiQL, um IDE interativo que permite explorar e testar consultas GraphQL, além de bibliotecas em várias linguagens de programação que facilitam a integração do GraphQL em aplicativos existentes.
Pontos Negativos do GraphQL:
Curva de Aprendizado: Embora a ideia central do GraphQL seja simples, pode haver uma curva de aprendizado ao entender todos os conceitos e padrões associados. Isso pode ser especialmente verdadeiro para desenvolvedores acostumados com abordagens RESTful tradicionais.
Overfetching em Recursos Existentes: Embora o GraphQL seja eficiente para buscar apenas os campos necessários, pode haver casos em que os recursos existentes não são projetados para serem buscados dessa maneira. Isso pode levar a situações em que o GraphQL ainda busca mais dados do que o necessário, resultando em overfetching.
Complexidade do Servidor: Implementar e gerenciar um servidor GraphQL pode ser mais complexo do que uma API RESTful simples. Isso ocorre porque o servidor GraphQL precisa resolver consultas complexas e gerenciar a lógica de negócios para atender às necessidades específicas dos clientes.
Caching: O GraphQL não possui um mecanismo de cache embutido, o que significa que os desenvolvedores precisam implementar sua própria camada de cache para melhorar o desempenho. Isso pode adicionar complexidade ao desenvolvimento e à manutenção da API.
E qual escolher?
Em última análise, a escolha entre GraphQL e RestAPI depende das necessidades e requisitos do projeto.
Sua equipe é grande e não tem comunicação entre front-end e back-end? Não utiliza cache e não quer sofrer com overfetching? Recomendamos o GraphQL, claro, se os desenvolvedores estiverem habituados com isso.
Se a sua equipe não está habituada, você precisa de uma API simples e fácil de entender, que não vai te dar dor de cabeça que é fácil de implementar e que você não precisa de uma documentação extensa, recomendo o RestAPI. Mas, ainda será necessário ambos os setores da aplicações ter uma comunicação para que não haja overfetching e underfetching.
Claro que isso não é uma obrigação, apenas, uma recomendação. Não leve isso como uma verdade absoluta, pois, cada projeto é um projeto, e cada um tem suas necessidades. Dúvidas? Pode me questionar!