{"id":49288,"date":"2025-03-26T16:30:40","date_gmt":"2025-03-26T19:30:40","guid":{"rendered":"\/tutoriais\/?p=49288"},"modified":"2025-03-26T16:30:42","modified_gmt":"2025-03-26T19:30:42","slug":"graphql-vs-rest","status":"publish","type":"post","link":"\/br\/tutoriais\/graphql-vs-rest","title":{"rendered":"GraphQL vs REST: qual o melhor para o desenvolvimento de API?"},"content":{"rendered":"

API é uma sigla em inglês para Application Programming Interface<\/em>, que significa Interface de Programação de Aplicações. Ela é um software intermediário que permite que uma aplicação se comunique com outras sem precisar saber como eles foram implementados, tanto pode ser um servidor, um cliente ou um aplicativo que se comunica com um servidor. Abaixo trouxemos uma linha do tempo que exemplifica como essa interface tem evoluído ao longo dos anos, e estabelece uma excelente base de como a API pode ser construída. O REST continua sendo a ferramenta mais popular para o desenvolvimento de APIs. Porém, em 2012, o Facebook procurava algo diferente do REST e foi aí que o GraphQL (sigla em inglês para Graph Query Language<\/em>) surgiu. <\/p>

\n
\"\"
Fonte: https:\/\/blog.api.rakuten.net\/graphql-vs-rest\/<\/figcaption><\/figure><\/div>

O que é REST?<\/strong><\/h2>

REST é uma API de Transferência de Estado Representacional (Representational Sate Tranfer<\/em>), o que significa que cada recurso tem seu próprio endpoint (ponto de extremidade). Inicialmente, o termo REST foi introduzido e definido em 2000, na tese de doutorado de Roy Fielding e foi popularizado por empresas como o Twitter em 2006. REST é um conceito de arquitetura de software baseado em rede. Ele não tem nenhum conjunto de ferramentas oficial, nenhuma especificação, não importa se você usa protocolo HTTP, AMQP, etc. O REST foi projetado para desacoplar uma API do cliente. <\/p>

Os Principais Desafios do REST API<\/strong><\/h2>

O REST API, às vezes, requer uma Maior Latência.<\/strong> Isso acontece quando precisamos mostrar alguns dados que devem ser consumidos de diferentes endpoints e o consumo de dados de apenas um único endpoint não é suficiente. A tabela a seguir ilustra três endpoints:<\/p>

GET \/user<\/td>Busca uma lista de todos os usuários<\/td><\/tr>
GET \/user\/:id<\/td>Busca um único usuário :id<\/td><\/tr>
GET \/user\/:id\/projects<\/td>Busca todos os projetos de um usuário<\/td><\/tr><\/tbody><\/table><\/figure>

E se precisássemos buscar projetos em um aplicativo cliente relacionados a um usuário específico e algumas tarefas também relacionados a este projeto? A equipe back-end precisa desenvolver algo mais? Existem algumas maneiras de fazer isso, elas são as seguintes:<\/p>

    \n
  1. Para incluir uma consulta e depois fazer as tarefas retornar a cada projeto: GET \/users:id\/projects?include=tasks<\/li>\n\n\n\n
  2. Para separar o endpoint, os recursos do projeto e pedir a um aplicativo cliente a filtragem de consulta com base no id do usuário: GET \/projects?userid=:id&include=tasks<\/li>\n\n\n\n
  3. Para incluir todos os dados possíveis associados ao usuário em um único endpoint: GET \/tasks?userid=:id<\/li>\n<\/ol>

    Over-fetching<\/em><\/strong> (excesso de dados) e Under-fetching<\/em> (dados insuficientes).<\/strong> Quando há necessidade de retornar muitos dados, o aplicativo cliente não precisa de todos esses dados. Seus clientes podem não ficar satisfeitos se forem obrigados a baixar informações adicionais desnecessárias. Por outro lado, ao reduzir o nível de informações em um servidor, outro problema pode ser enfrentado: o de consulta insuficiente (under-fetching), o que resulta na necessidade de mais um endpoint e mais recursos em um servidor para conseguir acessar os dados solicitados. A solução para é: GET \/users?fields=firstname,lastname. <\/p>

    Dificuldade em criar versões e substituir campos que não são necessários para os próximos lançamentos<\/strong>. É difícil manter o REST APIs ao longo do tempo, são feitas diferentes solicitações para suportar diversas versões de aplicativos e vários clientes. É por isso que, normalmente, a v1 permanece como ela é, e a v2 é criada a partir de uma estrutura de dados mais recente. Já com GraphQL, isso pode ser feito sem controle de versões. O GraphQL retorna apenas dados explicitamente solicitados, assim, novos recursos podem ser adicionados por meio de novos tipos e novos campos sobre esses tipos sem criar um breaking change<\/em> (uma ação que quebra a compatibilidade da API). O que levou à uma prática comum de evitar breaking changes<\/em> contínuas e entregar uma API sem versões.<\/p>

    Dados imprevisíveis<\/strong>. Com o REST não dá para saber quais dados serão retornados do servidor, quais campos, quantos deles etc. Já com o GraphQL, o cliente determina quais campos ele deseja consultar. Não importa se é uma query<\/em> (consulta) ou uma mutation<\/em> (mudanças no conteúdo) — você é quem controla o que será retornado.<\/p>

    O que é GraphQL?<\/strong><\/h2>

    O GraphQL é um conceito mais recente que o REST, ele foi lançado oficialmente pelo Facebook em 2012 e se tornou open source<\/em> (código aberto) em 2015. O GraphQL, por ser uma nova forma de solicitar dados para um servidor, é uma linguagem de consulta (query language),<\/em> especificação e coleção de ferramentas desenvolvida para operar sobre um único endpoint através do HTTP, que otimiza o desempenho e a flexibilidade. <\/p>

    A tabela a seguir compra o GraphQL e o REST como duas abordagens de desenvolvimento de API. Em termos gerais, não podemos considerar essa comparação como uma forma de apontar qual é o melhor entre os dois, mas sim, para entender a melhor opção de acordo com a natureza do seu projeto, já que o REST é o padrão convencional para o desenvolvimento de APIs e o GraphQL é uma linguagem de consulta que ajuda a resolver problemas com as APIs.  ? <\/p>

    A principal diferença aqui é que o GraphQL é uma linguagem voltada ao cliente. Sua arquitetura permite que o aplicativo front-end determina quais dados devem ser pesquisados e a quantidade de dados que deve ser retornada ao servidor. Já no REST, tudo é projetado no servidor, logo, o servidor é o responsável pela arquitetura. <\/p>

    GraphQL<\/strong><\/td>REST<\/strong><\/td><\/tr>
    Uma linguagem de consulta que oferece eficiência e flexibilidade na resolução de problemas comuns durante a integração de APIs.<\/td>Um modelo arquitetônico de software amplamente conhecido como um padrão convencional para o desenvolvimento de APIs.<\/td><\/tr>
    Implementado por HTTP usando um único endpoint que fornece todos os recursos do serviço exposto<\/td>Implementado por um conjunto de URLs em que cada uma delas exibe um único recurso<\/td><\/tr>
    Arquitetura voltada ao cliente<\/td>Arquitetura voltada ao servidor<\/td><\/tr>
    Não tem armazenamento de cache automático<\/td>Tem armazenamento de cache automático<\/td><\/tr>
    Sem controle de versão para API<\/td>Suporta várias versões de API<\/td><\/tr>
    Apenas representação JSON<\/td>Suporta diversos formatos de dados<\/td><\/tr>
    Apenas uma ferramenta é utilizada para a documentação: GraphiQL<\/td>Ampla gama de opções para documentação automatizada, como OpenAPI e API Blueprint<\/td><\/tr>
    É mais difícil identificar erros pelos códigos de status HTTP<\/td>Utiliza diferentes códigos de status HTTP para facilitar a identificação de erros<\/td><\/tr><\/tbody><\/table><\/figure>

    Motivos para Usar o GraphQL<\/strong><\/h2>

    Há três motivos principais que nos levam a querer usar o GraphQL em vez do REST. <\/p>