Qual o melhor protocolo para eu adotar na construção da minha nova API? Trabalhei com REST durante toda a minha carreira, será que é o melhor protocolo? Ou ainda, REST, SOAP e GraphQL são realmente protocolos? Qual sua definição? Qual problema eles resolvem?
Essas dúvidas assolam muitos desenvolvedores no início da carreira ou que não tiveram oportunidade de trabalhar com mais de uma dessas tecnologias. Este artigo pretende jogar uma luz de forma sucinta em conceitos importantes que muitas vezes são deixados de lado e as vantagens e desvantagens de cada um desses estilos arquiteturais. Spoiler: não existe bala de prata.
Por definição, apenas SOAP é de fato um protocolo. REST é um conjunto de princípios e restrições arquiteturais adotadas por convenção. Já o GraphQL muda o paradigma que estamos acostumados por ser uma Query Language, onde é possível traçar um paralelo com outras Query Languages como SQL.
Cada padrão é especialista no que se propõe, cabe ao desenvolvedor entender suas particularidades e escolher a mais adequada. Bora entender melhor essas abordagens?
SOAP
SOAP (Simple Object Access Protocol) é um protocolo padrão introduzido em 1998 para que aplicações rodando em diferentes linguagens e plataformas pudessem se comunicar. Por ser um protocolo, ele contém uma série de regras integradas que aumentam a complexidade das integrações e o overhead das requisições. Por outro lado, essas regras, que estão em conformidade com os princípios ACID (atomicity, consistency, isolation & durability), garantem uma confiabilidade e robustez elevada, o que pode ser ideal para o caso de uso de sistemas enterprise, de alta segurança, distribuídos e serviços financeiros.
SOAP é capaz de manusear requisições através de todos os protocolos da camada de aplicação do modelo OSI (HTTP, SMTP (para email), TCP, dentre outros), o que é uma vantagem sobre os outros modelos arquiteturais.
As requisições e respostas adotam o formato XML e não são guardadas em cache pelo browser. Ainda, o SOAP permite arquiteturas stateful (onde o contexto da requisição atual depende das anteriores) e stateless.
REST
REST (Representational State Transfer) foi introduzido em 2000 por Roy Fielding como princípios de design que visavam facilitar o entendimento e padronizar o formato de requisições HTTP. Por ser apenas um conjunto de diretrizes (ao invés de um padrão ou protocolo) existe muita flexibilidade na implementação dessas recomendações.
Em geral, por oferecer mais liberdade no desenvolvimento, o REST é preferido e considerado mais fácil de usar que seus pares. Apesar disso, existem critérios que precisam ser cumpridos para que uma API possa ser considerada RESTful, dentre eles:
- A arquitetura deve ser composta por cliente, servidor e recursos, com requisições gerenciadas por HTTP;
- Comunicação Stateless entre cliente e servidor – Dados da sessão não são armazenados no servidor, e sim no cliente;
- Dados devem poder ser guardados em cache;
- Uma interface uniforme entre componentes, garantindo um padrão na transferência de informação: essa é a feature central que diferencia o REST das outras abordagens.
Outro ponto onde o REST oferece mais liberdade é no formato das requisições. JSON é o formato padrão da indústria, por possuir interfaces em todas as linguagens de programação e ser menos verboso, facilitando a leitura por humanos e diminuindo o overhead de processamento. Apesar disso, APIs RESTful podem ser construídas utilizando HTML, XML e plain text além do JSON.
A flexibilidade na implementação das diretrizes do REST faz com que as APIs que o utilizam sejam em geral mais leves, rápidas e escaláveis, proporcionando uma maior agilidade no desenvolvimento.
GraphQL
Abreviação de Graph Query Language, o GraphQL chega chutando o balde dos modelos existentes e introduzindo um novo paradigma para a criação de APIs.
Com o crescimento da computação móvel e o aumento no volume de dados sendo transferidos através de redes com capacidade limitada, o Facebook identificou a necessidade de uma solução mais performática e assim, em 2015 o GraphQL foi introduzido ao público.
Enquanto os modelos anteriores realizam transferências de dados com estruturas fixas, onde muitas vezes recebemos mais dados que o necessário ou precisamos realizar múltiplas chamadas em endpoints diferentes, o GraphQL oferece total controle ao cliente sobre a estrutura e volume dos dados transmitidos – o que economiza rede, processamento e torna o GraphQL uma opção extremamente performática.
Outra mudança drástica do GraphQL para o que vimos anteriormente é a eliminação da necessidade de múltiplos endpoints – existe apenas uma rota onde rodamos as queries, e o GraphQL se responsabiliza por obter dados de múltiplos pontos, relacioná-los e retorná-los ao cliente no formato por ele requisitado.
Um Schema fortemente tipado é mantido no servidor cumprindo a função de contrato e mantendo padrões. Comparado ao Schema WSDL do SOAP, o GraphQL inova por prover liberdade na consulta de dados por parte do cliente, a responsabilidade do backend é apenas definir e manter o Schema.
O GraphQL também possui limitações que podem torná-lo inadequado para alguns projetos, principalmente para aplicações com queries demasiadamente complexas onde a construção de uma API REST ou SOAP com lógica customizada seria mais adequada. Além disso, o GraphQL não oferece suporte para transferência de arquivos e seus servidores podem ficar congestionados se não houver boa manutenção.
E no fim das contas?
Ah, no final das contas, é responsabilidade do desenvolvedor entender a particularidade de cada abordagem e escolher a ferramenta certa para cada serviço! A escolha arquitetural correta é apenas um de muitos passos no caminho para a construção de códigos mais limpos e aplicações mais eficientes.
Quer saber mais? Então clique aqui e ouça o Podcast Code Your Way!
Referências
https://www.redhat.com/en/topics/api/what-is-a-rest-api
https://www.redhat.com/en/topics/integration/whats-the-difference-between-soap-rest
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
