Como os canais através dos quais os componentes de software interagem e os dados fluem pela internet, as APIs são a força vital dos serviços da web contemporâneos. Tecnologias de API como SOAP (um protocolo de mensagens de serviços da web), REST (um estilo arquitetônico) e GraphQL (uma linguagem e ferramenta de programação) simplificam o desenvolvimento de software, permitindo a integração de dados e serviços de terceiros. As APIs também permitem que as empresas ofereçam funções de serviço seguras e troca de dados para funcionários, parceiros de negócios e usuários.
Apesar dos muitos tipos de APIs, debates sobre dois grandes paradigmas dominaram a conversa nos últimos anos: REST (transferência de estado representacional) e GraphQL. Ambos oferecem uma série de benefícios e, portanto, são implementados em projetos de rede no mundo todo. No entanto, eles diferem significativamente na forma como gerenciam o tráfego de dados. Aqui, dissecamos essas diferenças e discutimos como as empresas podem usar APIs REST e GraphQL para otimizar suas redes.
Uma compreensão das APIs REST e GraphQL individualmente é necessária para uma comparação das duas.
Desenvolvida no início dos anos 2000, a REST é um estilo arquitetural estruturado para aplicativos hipermídia em rede, projetada para usar um protocolo de comunicação cliente/servidor, sem estado e que pode ser armazenado em cache. As APIs REST, também chamadas de APIs RESTful, são os impulsionadores das arquiteturas REST.
As APIs REST usam identificadores de recursos exclusivos (URIs) para endereçar recursos. As APIs REST funcionam fazendo com que diferentes endpoints executem operações CRUD (“criar”, “ler”, “atualizar” e “excluir” - “create,” “read,” “update” and “delete”) para recursos de rede. Elas se baseiam em um formato de dados predefinido, chamado de tipo de mídia ou tipo MIME, para determinar a forma e o tamanho dos recursos que fornecem aos clientes. Os formatos mais comuns são JSON e XML (e, às vezes, HTML ou texto simples).
Quando o cliente solicita um recurso, o servidor processa a consulta e retorna todos os dados associados a esse recurso. A resposta inclui códigos de resposta HTTP como "200 OK" (para solicitações REST bem-sucedidas) e "404 Not Found" (para recursos que não existem).
A GraphQL é uma linguagem de consulta e tempo de execução de API que o Facebook desenvolveu internamente em 2012 antes de se tornar de código aberto em 2015.
A GraphQL é definida pelo esquema de API escrito na linguagem de definição de esquema da GraphQL. Cada esquema especifica os tipos de dados que o usuário pode consultar ou modificar e as relações entre os tipos. Um resolvedor protege cada campo em um esquema. O resolvedor fornece instruções para transformar consultas, mutações e assinaturas da GraphQL em dados e recupera dados de bancos de dados, serviços de nuvem e outras fontes. Os resolvedores também fornecem especificações de formatação de dados e permitem que o sistema una dados de várias fontes.
Ao contrário da REST, que normalmente usa vários endpoints para buscar dados e executar operações de rede, a GraphQL expõe modelos de dados usando um único endpoint por meio do qual os clientes enviam solicitações da GraphQL, independentemente do que estão solicitando. Em seguida, a API acessa as propriedades do recursos e segue as referências entre os recursos para obter do cliente todos os dados necessários de uma única consulta ao servidor GraphQL.
As APIs GraphQL e REST são intercâmbios de dados baseados em recursos que usam métodos HTTP (como solicitações PUT e GET) que determinam quais operações um cliente pode realizar. No entanto, existem diferenças importantes entre elas que explicam não apenas a proliferação da GraphQL, mas também por que os sistemas RESTful têm esse poder de permanência.
A GraphQL é uma adição eficiente e mais flexível à REST; a APIs GraphQL são frequentemente vistas como um upgrade em relação aos ambientes RESTful, especialmente devido à sua capacidade de facilitar a colaboração entre as equipes de front-end e back-end. A GraphQL oferece um próximo passo lógico na jornada de API de uma organização, ajudando a corrigir problemas que normalmente são encontrados com a REST.
No entanto, a REST foi por muito tempo o padrão para arquiteturas de API, e muitos desenvolvedores e arquitetos ainda dependem de configurações RESTful para gerenciar suas redes de TI. Por isso, entender as diferenças entre as duas é essencial para a estratégia de gerenciamento de TI de qualquer organização.
As APIs REST e GraphQL diferem na forma como gerenciam:
Como a REST depende de vários endpoints e interações stateless, em que cada solicitação de API é processada como uma nova consulta, independente de qualquer outra, os clientes recebem todos os dados associados a um recurso. Se um cliente precisar apenas de um subconjunto dos dados, ele ainda receberá todos os dados (busca excessiva). E se o cliente precisar de dados que abranjam vários recursos, um sistema RESTful geralmente faz com que o cliente consulte cada recurso separadamente para compensar a recuperação inadequada de dados da solicitação inicial (busca insuficiente). As APIs GraphQL usam um único endpoint da GraphQL para oferecer aos clientes uma resposta de dados precisa e abrangente em uma única viagem de ida e volta a partir de uma única solicitação, eliminando problemas de busca excessiva e insuficiente.
Em uma arquitetura REST, as equipes devem versionar as APIs para modificar as estruturas de dados e evitar erros no sistema e interrupções no serviço para o usuário final. Em outras palavras, os desenvolvedores devem criar um novo endpoint sempre que fizerem alterações, o que pode resultar em várias versões da API, podendo complicar a manutenção. A GraphQL reduz a necessidade de versionamento, porque os clientes podem especificar seus requisitos de dados na consulta. A adição de novos campos ao servidor não afeta os clientes sem a necessidade desses campos. Por outro lado, se os campos forem descontinuados, os clientes poderão continuar a solicitá-los até que as consultas sejam atualizadas.
As APIs REST devem usar códigos de status HTTP para indicar o status ou sucesso de uma solicitação, e cada código de status tem um significado específico. Uma solicitação HTTP bem-sucedida retorna um código de status 200, enquanto um erro do cliente pode retornar um código de status 400 e um erro do servidor pode retornar um código de status 500.
À primeira vista, essa abordagem de relatório de status parece mais simples, mas os códigos de status HTTP costumam ser mais úteis para os usuários da web do que para as próprias APIs, especialmente no caso de erros. A REST não possui uma especificação para erros e, portanto, os erros da API podem aparecer como erros de transporte ou não aparecer com o código de status. Essa dinâmica pode forçar a equipe a ler toda a documentação de status para entender o que os erros significam ou até mesmo como os erros são comunicados na infraestrutura.
Com APIs GraphQL, cada solicitação, independentemente de ter resultado em um erro, retorna um código de status 200 OK, pois os erros não são comunicados por meio de códigos de status HTTP (exceto para erros de transporte). Em vez disso, o sistema comunica erros no corpo da resposta juntamente com os dados; então, os clientes devem analisar a carga útil de dados para determinar se a solicitação foi bem-sucedida.
Dito isso, a GraphQL tem uma especificação para erros e, portanto, os erros da API são mais facilmente distinguíveis dos erros de transporte. A natureza exata dos erros aparece na entrada "errors" (erros) no corpo da resposta, o que pode tornar as APIs GraphQL preferíveis para criação.
A REST não possui compatibilidade integrada para atualizações em tempo real. Se um aplicativo precisar de funcionalidade em tempo real, os desenvolvedores geralmente devem implementar técnicas como sondagem longa (em que o cliente sonda repetidamente o servidor em busca de novos dados) e eventos enviados pelo servidor, o que pode adicionar complexidade à aplicação.
No entanto, a GraphQL inclui compatibilidade integrada com atualizações em tempo real por meio de assinaturas. As assinaturas mantêm uma conexão constante com o servidor, permitindo que o servidor envie atualizações para o cliente sempre que eventos específicos ocorrerem.
O ambiente REST está bem estabelecido, com uma ampla variedade de ferramentas, bibliotecas e estruturas disponíveis para desenvolvedores. Trabalhar com APIs REST, no entanto, também exige que as equipes naveguem por vários endpoints e entendam as convenções e padrões únicos de cada API.
As APIs GraphQL são relativamente novas, mas o ambiente da GraphQL cresceu tremendamente desde sua introdução, com diversas ferramentas e bibliotecas disponíveis tanto para o desenvolvimento de servidores quanto clientes. Ferramentas como GraphiQL e GraphQL Playground fornecem poderosos ambientes de desenvolvimento (IDEs) integrados no navegador para explorar e testar APIs GraphQL. Além disso, a GraphQL tem sólida compatibilidade com geração de código, o que pode simplificar o desenvolvimento no lado do cliente.
As APIs REST dependem de mecanismos como eTags e cabeçalhos de última modificação para armazenar em cache chamadas de API. Embora eficazes, essas estratégias de cache podem ser complexas de implementar e podem não ser adequadas para todos os casos de uso.
As APIs GraphQL podem ser mais difíceis de armazenar em cache devido à natureza dinâmica das consultas. No entanto, a implementação de consultas persistentes, cache de resposta e cache do lado do servidor pode atenuar esses desafios e otimizar esforços de cache mais amplos em arquiteturas GraphQL.
Nem as APIs REST nem as GraphQL são inerentemente superiores; são ferramentas diferentes, adequadas a tarefas diferentes.
A REST geralmente é mais fácil de implementar e pode ser uma boa opção quando se prefere um protocolo de comunicação simples e armazenável em cache com controles de acesso rigorosos (para sites de comércio eletrônico voltados para o público, como Shopify e GitHub, por exemplo). Dados os riscos de busca reduzida e excessiva, as APIs REST são melhores para:
As APIs GraphQL permitem a busca de dados mais flexível e eficiente, o que pode melhorar o desempenho do sistema e a facilidade de uso para os desenvolvedores. Esses recursos tornam a GraphQL especialmente útil para construir APIs em ambientes complexos com requisitos de front-end em rápida evolução. Isso inclui:
Embora usem abordagens diferentes, as APIs GraphQL e REST têm o potencial de melhorar muito a escalabilidade da rede e o desempenho do servidor.
Independentemente de você optar por implantar APIs REST ou GraphQL, ou alguma combinação das duas, sua empresa pode se beneficiar de uma ampla variedade de aplicações em potencial, incluindo implementações em várias linguagens de programação (como JavaScript) e integração com microsserviços e arquiteturas serverless . Com o IBM API Connect, você pode usar os dois tipos de APIs para otimizar sua infraestrutura de TI.
O IBM API Connect é uma solução completa de gerenciamento do ciclo de vida das APIs que o ajudará a criar, gerenciar, proteger, socializar e monetizar APIs, além de promover a transformação digital em ambientes de data centers e nuvem. Isso significa que tanto as empresas quanto os clientes podem impulsionar aplicativos digitais e estimular a inovação em tempo real.
Com o API Connect, as empresas podem ajudar a garantir que estejam operando na vanguarda do API Management, o que será inestimável em um cenário de computação que está preparado para se tornar maior, mais complexo e mais competitivo com o tempo.