Por muito tempo, as interfaces de sistemas desenvolvidas tinham como foco satisfazer as necessidades do usuário final, ou seja, eram baseadas em interação Humano-Computador.
No entanto, a complexidade oriunda do crescimento da internet nos trouxe um novo problema. Alguns sistemas precisavam de informações fornecidas por um outro sistema para satisfazer seu usuário final. Surge então a questão: “Como padronizar a interação entre dois sistemas” na rede?
Este artigo descreve brevemente as 3 soluções que, ao longo do tempo, acabaram se popularizando na busca por solucionar essa questão:
- SOAP (Simple Object Access Protocol)
- REST (REpresentation State Transfer)
- GraphQL (Query Language for APIs)
1. SOAP (Simple Object Access Protocol)
No final do último milênio, mais especificamente em 1998, o SOAP surge como um protocolo de especificação de troca de informações estruturadas para implementação de web services em redes de computadores, dentre elas a internet, é claro.
Essa primeira grande tentativa de implementar uma solução para o problema descrito acima tinha como principais propósitos/características a extensibilidade (podendo ser usada para criar soluções mais específicas), a neutralidade (podendo operar sobre qualquer protocolo de transporte como HTTP, SMTP, TCP ou UDP) e a independência (permitindo sua utilização por qualquer modelo de negócio).
Mas a palavra “simples” no nome do protocolo se mostra relativa quanto à sua implementação. Cada sistema SOAP arquitetado utiliza WSDL (Web Service Description Language) para descrever seu próprio contrato de serviço.
Esse contrato de serviço define os objetos pertencentes ao sistema e as operações que podem ser realizadas sobre eles. Isso significa que todo outro sistema que queira se comunicar com ele deverá seguir este contrato de serviço.
Já conseguiu imaginar por que não é tão simples?
Imagina se um sistema precisa se comunicar com outros 5 sistemas para obter informações relevantes ao seu usuário final. São 5 contratos de serviços, cada um à sua maneira, com objetos e transações distintos que precisam ser mapeados. Deu até frio na barriga, não é?
2. REST (REpresentation State Transfer)
Ao contrário do SOAP, REST não é um protocolo, mas sim um estilo de arquitetura de software que define uma série de regras para a criação de Web services. Você já deve ter encontrado threads na internet discutindo se determinada API é ou não RESTful, mas essa polêmica é assunto pra outro artigo.
O fato é que a partir da dissertação de doutorado de Roy Thomas Fielding em 2000, onde ele descreve os princípios da arquitetura REST, uma alternativa mais padronizável surgiu na comunicação entre sistemas na internet. Uma série de operações stateless (onde não se mantém nenhuma informação de contexto de um request para o outro) é predefinida e todos os sistemas REST utilizam este padrão.
Surgem então as chamadas APIs REST e suas operações sobre o protocolo HTTP. Isso significa que os modelos de objetos podem mudar de um sistema para o outro, mas as operações sobre eles se limitarão aos tipos de mensagem HTTP como GET, POST, PUT, DELETE, PATCH, OPTIONS, etc.
Outras características REST são relevantes e entram nas discussões acaloradas citadas acima sobre o que é genuinamente uma API RESTful, mas o fato de padronizar as operações facilitou a comunicação entre sistemas arquitetados por diferentes equipes e causou uma rápida popularização desse tipo de arquitetura ao longo dos anos que se seguiram.
3. GraphQL (Query Language for APIs)
Como era de se esperar, a chegada de uma nova solução sempre vem acompanhada do surgimento de novos problemas. APIs REST trazem uma peculiaridade relativamente custosa.
Imagine que você queira recuperar o nome e sobrenome de um Usuário em uma API. Para isso, você precisa requisitar, em um endpoint, todos os dados desse usuário. Isso faz com que sua mensagem de resposta venha recheada de dados que você não vai usar, como endereço, data de nascimento, email e etc.
Imagine agora que você você não queira apenas os dados desse usuário, mas também os dados dos dependentes vinculados a ele.. Sua primeira requisição, no endpoint de Usuário, não vem com todos os dados que você necessita.
Você precisaria pegar a lista de IDs dos N dependentes, por exemplo, e efetuar N requisições no endpoint de requisição dos dados de dependente para obter todas as informações necessárias.
Como uma solução para este problema, em 2015 o Facebook tornou pública uma linguagem de consulta e manipulação de dados de APIs, a GraphQL. Funcionando como uma interface a mais entre os sistemas, a proposta é ter apenas um ponto de entrada para a API, ao contrário dos vários endpoints do REST, onde poderiam ser recuperados exatamente os dados necessários em apenas uma determinada requisição, nem mais dados (overfetching), nem menos dados (underfetching) do que o necessário.
Esta é uma solução que vem se popularizando ao longo dos últimos anos. Mas não se engane, assim como as anteriores não resolveram, esta também não resolve todos os problemas que apareceram ou aparecerão na comunicação entre sistemas na Web.
Conclusão
As 3 soluções apresentadas neste artigo possuem seus prós e contras. SOAP ainda é muito utilizado em domínios que precisam de um contrato de serviço mais restrito e customizado, como os sistemas bancários de transação financeira.
REST é de longe a solução de arquitetura mais utilizada atualmente. E GraphQL não necessariamente elimina o uso de APIs REST, pois podem funcionar como interface entre várias APIs, mapeando seus endpoints para sistemas clientes.
No fim das contas vale a frase de Uri Levine (fundador do Waze): “Apaixone-se pelo problema, não pela solução”. Conheça bem que problema que cada uma das soluções busca resolver. Isso fará com que a escolha por uma delas seja mais assertiva para o contexto em que você está imerso.
Sugestões, dúvidas, comentários sobre o assunto? Escreve pra gente nos comentários!
