- Tendências dos protocolos de API e seus prós/contras, organizados pelo Postman com base em uma pesquisa com 40 mil desenvolvedores
- REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC etc.
REST
- Ainda é o mais usado. Caiu de 92% para 86% nos últimos 2 anos
- Simplicidade, escalabilidade e facilidade de integração com serviços web
- Vantagens do REST
- Simplicidade e padronização: usa métodos HTTP padrão, permitindo adoção fácil por desenvolvedores já familiarizados com HTTP. A simplicidade acelera o aprendizado e a integração
- Escalabilidade: por ser stateless, o servidor não precisa armazenar dados de sessão entre requisições. Isso facilita a escalabilidade horizontal ao adicionar instâncias sem precisar de servidores compartilhados
- Desempenho: respostas stateless e cacheáveis aumentam a velocidade de execução e reduzem o número de requisições
- Modularidade: serviços RESTful podem ser desenvolvidos como componentes modulares. Isso permite atualizações independentes e melhora a manutenibilidade
- Independência de plataforma: pode ser usado com diversos clientes. A interoperabilidade facilita a integração de APIs em todo o sistema
- Ferramentas maduras e apoio da comunidade: há muitas ferramentas, bibliotecas, boas práticas, guias de resolução de problemas e recursos da comunidade
- Desafios do REST
- Over-fetching e under-fetching: o cliente pode precisar de apenas parte dos dados, o que faz com que se busque dados demais ou de menos. Isso pode causar problemas de desempenho e desperdiçar largura de banda
- Múltiplas interfaces: buscar dados relacionados pode exigir várias requisições, aumentando a latência. Essa sequência de chamadas vira problema à medida que a aplicação cresce
- Problemas de versionamento: criar novas versões de APIs REST pode ser trabalhoso, especialmente quando mudam a estrutura de dados ou as funcionalidades do serviço. Isso frequentemente gera problemas de compatibilidade com versões anteriores
- Overhead do modelo stateless: embora o stateless ajude na escalabilidade, ele também exige fornecer todo o contexto necessário em cada requisição. Isso pode gerar overhead, especialmente quando o cliente precisa enviar grandes volumes de dados repetidos
- Falta de recursos em tempo real: REST não é otimizado para apps em tempo real, como chat ou feeds ao vivo. WebSocket e SSE são mais adequados para esses casos de uso
WebHooks
- Webhooks são callbacks HTTP personalizados disparados por eventos na aplicação de origem
- Quando um evento ocorre, a aplicação de origem envia uma requisição HTTP, geralmente
POST, para o URI especificado pela aplicação de destino, permitindo comunicação orientada a eventos quase em tempo real sem polling repetitivo
- Webhooks estão ganhando popularidade, e 36% dos desenvolvedores os usam para integração fluida entre diferentes sistemas
- Vantagens dos WebHooks
- Comunicação em tempo real: webhooks permitem transmitir dados em tempo real. Quando um evento acontece, os dados são enviados, garantindo sincronização atualizada entre sistemas
- Eficiência: webhooks eliminam polling intensivo em recursos, economizando capacidade computacional e largura de banda
- Flexibilidade: webhooks podem ser configurados para responder a eventos específicos, permitindo personalizar quais ações ou gatilhos em uma aplicação enviarão dados para outra
- Integração simplificada: por usar métodos HTTP, podem ser usados facilmente na maioria das aplicações
- Suporte a arquitetura desacoplada: como webhooks operam com base em eventos, eles apoiam naturalmente arquiteturas orientadas a eventos ou desacopladas, melhorando modularidade e escalabilidade
- Desafios dos WebHooks
- Tratamento de erros: se o receptor do webhook estiver fora do ar ou houver erro ao processar o callback, existe risco de perda de dados. Sistemas que usam webhooks precisam de mecanismos robustos de tratamento de erros, incluindo retries ou logs
- Questões de segurança: como webhooks transmitem dados pela internet, ficam vulneráveis a interceptação ou ataques maliciosos. Medidas de segurança de API, como uso de HTTPS e assinatura do payload, são essenciais
- Gerenciamento de múltiplos webhooks: gerenciar e monitorar webhooks pode ser complexo, especialmente quando a aplicação cresce e passa a depender de vários deles. É preciso atenção para garantir que todos funcionem corretamente e para rastrear diferentes endpoints
- Possibilidade de sobrecarga: um grande volume de callbacks simultâneos pode sobrecarregar a aplicação receptora, embora rate limiting ou processamento em lote possam ajudar a lidar com picos
GraphQL
- GraphQL é uma linguagem de consulta para APIs e um runtime do lado do servidor para executar consultas usando um sistema de tipos definido para os dados
- Desenvolvido pelo Facebook em 2012 e lançado como projeto open source em 2015, o GraphQL oferece uma alternativa mais flexível e eficiente às APIs REST tradicionais
- O GraphQL vem aumentando sua adoção entre desenvolvedores, chegando a 29%, o que mostra sua importância no cenário atual de APIs
- Diferentemente do REST, que pode exigir vários endpoints de API para buscar dados relacionados, o GraphQL permite obter todos os dados necessários em uma única consulta
- Isso é especialmente útil para desenvolvedores front-end, pois dá mais controle sobre o processo de obtenção de dados e permite criar interfaces de usuário mais dinâmicas e responsivas
- Vantagens do GraphQL
- Schema fortemente tipado: APIs GraphQL têm schemas fortemente tipados, então os desenvolvedores sabem exatamente quais dados e tipos podem usar nas consultas
- Busca precisa de dados: o cliente pode solicitar exatamente os dados de que precisa, resolvendo over-fetching e under-fetching, além de melhorar o desempenho e reduzir custos
- Complexidade de consulta e múltiplos recursos: GraphQL suporta consultar vários tipos de dados em uma única requisição, reduzindo o número de chamadas de rede para dados complexos e inter-relacionados
- Atualizações em tempo real com subscriptions: GraphQL oferece sincronização em tempo real por meio de subscriptions, permitindo que os clientes recebam atualizações em tempo real
- Introspecção: o schema auto-documentado do GraphQL facilita o desenvolvimento por meio de autoinspeção
- Desafios do GraphQL
- Complexidade das consultas: a flexibilidade que o GraphQL oferece ao cliente também tem desvantagens. Consultas excessivamente complexas ou aninhadas podem impactar negativamente o desempenho
- Curva de aprendizado: GraphQL tem uma curva de aprendizado mais íngreme que REST por causa de novos conceitos como mutations e subscriptions
- Versionamento: a natureza flexível das consultas significa que mudanças no schema podem quebrar consultas existentes e complicar o versionamento
- Possibilidade de uso excessivo de recursos: como o cliente pode pedir vários recursos em uma única consulta, existe o risco de buscar mais dados do que o necessário e sobrecarregar o servidor
- Questões de segurança: usuários mal-intencionados podem explorar a flexibilidade do GraphQL para sobrecarregar o servidor com consultas complexas
SOAP
- SOAP (Simple Object Access Protocol) é um protocolo para troca de informações estruturadas na implementação de serviços web
- Usa XML como formato de mensagem e, em geral, HTTP ou SMTP como camada de negociação e transporte de mensagens
- Diferentemente de REST e GraphQL, o SOAP tem padrões rígidos e recursos embutidos, como transações compatíveis com ACID, segurança e padrões de mensageria
- Apesar da queda de uso para apenas 26% dos desenvolvedores, o SOAP continua sendo uma escolha confiável para aplicações específicas
- Vantagens do SOAP
- Tipagem forte e contrato: há tipagem forte e contratos rígidos definidos em documentos WDSL (Web Services Description Language)
- Recursos de segurança embutidos: SOAP oferece segurança abrangente por meio de autenticação, autorização e criptografia implementadas com o padrão WS-Security. Isso o torna uma escolha preferida para aplicações corporativas
- Transações ACID: SOAP oferece suporte a transações ACID, essenciais para aplicações em que a integridade dos dados é crítica, como sistemas financeiros ou de saúde
- Mensageria confiável: SOAP garante entrega confiável de mensagens e lida bem com erros, sendo muito adequado para sistemas em que garantias de entrega são importantes
- Neutralidade de linguagem, plataforma e transporte: assim como REST, serviços SOAP podem ser usados por qualquer cliente que entenda XML, independentemente da linguagem de programação, plataforma ou protocolo de transporte subjacente
- Desafios do SOAP
- Complexidade e curva de aprendizado: SOAP pode ser mais complexo de implementar devido aos padrões rígidos e ao uso de XML, o que torna sua curva de aprendizado mais íngreme do que alternativas como REST ou GraphQL
- Mensagens verbosas: os headers de mensagens SOAP carregam muito overhead, tornando o payload maior que o JSON usado por REST e GraphQL. Isso pode afetar o desempenho e o uso de largura de banda
- Suporte limitado da comunidade: SOAP vem perdendo espaço, o que significa redução no suporte da comunidade e nas bibliotecas disponíveis
- Menor flexibilidade: quando o contrato muda, tanto cliente quanto servidor podem precisar atualizar suas respectivas implementações, o que pode ser uma desvantagem
- Problemas com firewall: SOAP pode usar protocolos de transporte diferentes de HTTP/HTTPS, o que significa que pode enfrentar restrições de firewall. Isso reduz sua versatilidade em alguns ambientes de implantação
WebSocket
- WebSocket fornece uma conexão bidirecional persistente e de baixa latência entre cliente e servidor, permitindo transmissão de dados em tempo real
- Diferentemente do ciclo de requisição-resposta do HTTP, com WebSocket o servidor pode enviar dados ao cliente a qualquer momento após o handshake inicial
- Facilita atualizações imediatas de dados para aplicativos de chat, jogos online, plataformas de negociação etc.
- Segundo a pesquisa, 25% dos desenvolvedores usam WebSocket
- Vantagens do WebSocket
- Comunicação bidirecional em tempo real: a comunicação bidirecional em tempo real tem latência menor do que conexões HTTP que precisam ser restabelecidas a cada troca
- Redução de overhead: após o handshake inicial, a conexão permanece aberta, reduzindo o overhead dos headers presentes nas requisições HTTP tradicionais
- Uso eficiente de recursos: conexões persistentes usam recursos do servidor de forma mais eficiente do que long polling
- Desafios do WebSocket
- Complexidade de implementação: implementar WebSocket pode ser mais complexo e demorado do que outras arquiteturas de API, especialmente ao considerar a necessidade de fallback em ambientes sem suporte
- Falta de recursos embutidos: ao contrário do SOAP, que tem recursos embutidos para segurança e transações, WebSocket é mais básico, exigindo que o desenvolvedor implemente esses recursos por conta própria
- Consumo de recursos: conexões WebSocket abertas geralmente são mais eficientes que técnicas de long polling, mas ainda consomem recursos do servidor e isso pode virar problema em grande escala
- Limitações de rede: alguns proxies e firewalls não oferecem suporte a WebSocket, o que pode causar problemas potenciais de conexão em determinados ambientes de rede
gRPC
- gRPC, sigla para "Google Remote Procedure Call", é um protocolo moderno de alto desempenho que facilita a comunicação entre serviços
- É construído sobre HTTP/2 e usa Protocol Buffers para definir métodos de serviço e formatos de mensagem
- Diferentemente de APIs REST, que usam verbos HTTP padrão como GET e POST, o gRPC permite expor métodos personalizados em serviços, semelhantes a funções de uma linguagem de programação
- Vantagens do gRPC
- Desempenho: com HTTP/2 e Protocol Buffers, o gRPC consegue baixa latência e alto throughput
- Tipagem forte: assim como SOAP e GraphQL, gRPC é fortemente tipado. Como resultado, os tipos são validados em tempo de compilação, reduzindo bugs
- Suporte multilíngue: gRPC oferece suporte de primeira classe a várias linguagens de programação, incluindo Go, Java, C# e Node.js
- Streaming: gRPC lida diretamente com requisições e respostas em streaming, o que o torna aplicável a casos de uso complexos, como conexões de longa duração e atualizações em tempo real
- Baterias incluídas: gRPC oferece suporte direto a recursos importantes como balanceamento de carga, retries e timeouts
- Desafios do gRPC
- Suporte em navegadores: o suporte nativo a gRPC em navegadores ainda é limitado, então ele não é adequado para comunicação direta cliente-servidor em aplicações web
- Curva de aprendizado: desenvolvedores precisam aprender a usar Protocol Buffers, definições personalizadas de serviço e outros recursos do gRPC, o que pode reduzir a produtividade inicial
- Complexidade de depuração: como Protocol Buffers não é legível por humanos, depurar e testar APIs gRPC é mais difícil do que em APIs JSON
Outros protocolos de API
- MQTT: protocolo leve de mensageria otimizado para redes de baixa largura de banda, como IoT. Permite que clientes publiquem e assinem mensagens por meio de um broker, mas carece de alguns recursos de segurança e escalabilidade
- AMQP: padrão de mensageria corporativa mais robusto, que garante entrega confiável e roteamento flexível de mensagens. Porém, pode ser mais complexo e ter mais overhead do que protocolos leves
- SSE: permite comunicação unidirecional servidor-cliente via HTTP; é adequado para atualizações em tempo real, mas não tem capacidade bidirecional
- EDI: automatiza a comunicação B2B ao padronizar documentos eletrônicos como pedidos de compra e faturas, mas exige alto custo inicial e infraestrutura complexa
- EDA: promove arquitetura orientada a eventos, em que componentes reagem a eventos, permitindo sistemas em tempo real escaláveis, mas com depuração complexa
Conclusão
- O cenário de APIs continua evoluindo à medida que desenvolvedores adotam novas arquiteturas, protocolos e ferramentas
- REST ainda domina por causa de sua simplicidade e ubiquidade, mas alternativas como GraphQL e gRPC estão ganhando atenção ao resolver problemas como over-fetching e interfaces verbosas
- Além disso, desenvolvedores estão dando importância crescente a WebHooks e WebSocket por causa da demanda por comunicação em tempo real
- Em muitos casos de uso comuns de APIs, REST continua sendo uma abordagem padrão sólida, considerando escalabilidade, interoperabilidade e facilidade de adoção. Também se beneficia da maturidade da comunidade
- Ainda assim, todos os protocolos têm vantagens e desvantagens, e à medida que as aplicações ficam mais complexas, os desenvolvedores estão expandindo com inteligência seu toolkit de protocolos de API para incluir soluções especializadas como GraphQL e gRPC
- Em vez de uma solução única que sirva para tudo, o melhor para desenvolvedores de API é entender os pontos fortes e fracos de vários protocolos
- Ao projetar sistemas que combinam REST, WebHook, WebSocket, GraphQL e outras abordagens com vantagens próprias, os desenvolvedores podem criar APIs robustas, eficientes e fáceis de manter
- A popularidade de protocolos individuais continuará oscilando, mas a tendência mais importante no cenário de APIs é o aumento da diversidade
- Desenvolvedores devem adotar essa filosofia multiprotocolo para criar soluções de API ideais
3 comentários
Gostei bastante
Se não for uma tarefa simples e pontual, resolvida com uma única ação, transações não são indispensáveis? (Mesmo sendo algo essencial, concordo com a ironia de só agora passarem a priorizar REST haha)