BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Superando a substituição do REST

Superando a substituição do REST

Favoritos

Pontos Principais

  • Nos últimos dois anos, tem crescido o sentimento anti-REST na comunidade de desenvolvimento de software. No entanto, as tecnologias alternativas geralmente surgem dentro de um contexto particular, que apresenta pontos fortes e fracos em relação a casos de uso específicos;
  • A ascensão do REST foi alimentada por uma falsa dicotomia, com o SOAP desempenhando o papel de vilão. Enquanto o SOAP tentou fornecer um método de tunelamento por meio dos protocolos da web, a abordagem REST os adotou;
  • Em vez de substituir o REST, a indústria de engenharia de software deve procurar evoluir a maturidade do ecossistema REST, enquanto explora os pontos fortes tecnológicos dos novos protocolos.

Os novos protocolos de API como o GraphQL, o gRPC e o Apache Kafka, ganharam popularidade como alternativas para APIs HTTP inspiradas em REST. Este artigo argumenta que a força do paradigma REST não pode ser refletida em comparações individuais de protocolo. Em vez de substituir o REST, a indústria de engenharia de software deve procurar evoluir a maturidade do ecossistema REST, enquanto explora os pontos fortes tecnológicos dos novos protocolos.

Em protocolos, paradigmas e falsas dicotomias...

O recente post do blog de Vancouverite Tim Bray, "Post-REST", atraiu muita atenção por um bom motivo, como o uso de APIs na web cresceu, existe um ceticismo sobre o REST1 ser a convenção de comunicação ideal para as APIs na web. Além de seu escopo inicial de comunicação aberta na web, o REST também é usado para fornecer dados de aplicações web, fornecendo comunicação inter-microservice, facilitando a administração e automação de infra-estrutura e até mesmo padrões assíncronos como mensagens, distribuição de eventos e streaming.

A obra de Tim faz um bom trabalho ao descrever o uso do REST, suas limitações, algumas alternativas de protocolo emergentes (como GraphQL e gRPC) e especulações sobre o futuro da comunicação API na web. Embora, em geral, concorde com Tim, acredito que há mais a ser dito sobre o assunto. Ou seja, em vez de apenas olhar para o que poderia substituir o REST, gostaria que considerássemos como os pontos fortes do REST podem ser sintetizados com as inovações desses novos protocolos, para criar alternativas evolutivas na comunicação em ecossistemas de software distribuído.

Novos protocolos, velhas linhas de batalha, falsas dicotomias

Nos últimos dois anos, tem crescido o sentimento anti-REST na comunidade de desenvolvimento de software. Diversos artigos foram publicados reclamando das limitações do REST, e então apresentam um protocolo ou abordagem alternativa para comunicação.

O padrão "REST é ruim em x, então use y como alternativa" pode ser visto em partes como argumentos que suportam o GraphQL, gRPC, comunicação assíncrona e opções ainda mais obscuras. Os argumentos são mais ou menos esses:

  • O GraphQL é melhor que o REST porque permite que o consumidor da API controle os dados que recebe e permite que o provedor da API agregue recursos no lado do servidor;
  • O gRPC (mais buffers de protocolo) é melhor que o REST porque é type-safe, otimizou o desempenho por meio da serialização binária e é capaz de explorar os recursos do HTTP2;
  • A comunicação assíncrona (AMQP, Kafka, etc.) é melhor que a comunicação REST síncrona, porque reduz o bloqueio e o uso de thread e, portanto, aumenta a autonomia do serviço.

Cada uma dessas abordagens surgiu dentro de um contexto particular. O GraphQL foi criado pelo Facebook como parte de sua reformulação de seu aplicativo móvel. É o método de comunicação over-the-wire usado em conjunto com os frameworks JavaScript do Relay e React Native, essencialmente como um meio de disponibilizar dados ad hoc para o aplicativo. Sem surpresa, muitos proponentes públicos do GraphQL têm um viés em relação à centralização de dados e JavaScript. O gRPC e os buffers de protocolo surgiram do uso interno do Google e seguiram um caminho similar ao público como um projeto de orquestração de contêineres do Kubernetes. Espera-se que grande parte da defesa do gRPC seja centrada na comunicação entre aplicações baseadas em contêineres. A comunicação assíncrona exclusiva é frequentemente promovida para uso dentro do contexto de sistemas reativos ou fornecimento de eventos. Faz sentido que essas abordagens projetadas para cada um desses contextos específicos tenham algumas vantagens sobre a abordagem mais genérica do REST.

Em defesa do REST, é tentador considerar essas críticas e encontrar contrapontos como:

  • Para o caso do GraphQL, nada no paradigma REST impede a escolha do consumidor ou a agregação de recursos (tem sido apenas uma prática comum usar interfaces estáticas em recursos únicos) e há muitas informações sugerindo que restringir a escolha do consumidor tem seus próprios benefícios;
  • Para o gRPC, é improvável que a otimização do tempo de execução seja o principal gargalo na maioria das arquiteturas distribuídas, e o requisito de biblioteca embutida do gRPC - para não mencionar a estrutura enumerada do protobuf - pode levar a problemas imprevistos;
  • Para o assíncrono, é absolutamente necessário incluir cenários baseados em eventos, mas esses são provavelmente além de padrões síncronos como consultas e comandos.

No entanto, na minha opinião, esses contra-argumentos não contam toda a história.2 A engenharia de software é uma indústria inquieta e frequentemente simplificamos demais os problemas para justificar soluções excessivamente simplistas. Gostamos de rotular a "plataforma de queima" para que possamos incentivar as pessoas a adotarem uma nova segurança. O processamento em tempo real é bom porque o processamento em lote é ruim. Os microservices são bons porque os monólitos são ruins. Usar o REST como o vilão em uma base de contexto a contexto, como os argumentos anteriores, cria uma série de falsas dicotomias. Em vez de observar o que o REST carece em cada um dos cenários mencionados, talvez devêssemos examinar uma questão diferente: como o REST se tornou a abordagem de comunicação padrão na rede de componente para componente na computação distribuída? Vamos voltar ao início.

A origem, a ascensão e a onipresença do REST

O REST (Representational State Transfer) foi definido como um capítulo na dissertação de Ph.D. do Roy Fielding em 2000, "Architectural Styles and the Design of Network-based Software Architectures". O objetivo deste artigo foi "definir uma estrutura para entender a arquitetura de software ... para orientar o projeto arquitetônico do software baseado em rede". O REST foi incluído como o estilo de arquitetura de exemplo que codificou os princípios de desenho da World Wide Web, com ênfase na capacidade de evolução, escalabilidade e generalidade das interfaces. Em comparação com os contextos para as novas abordagens mencionadas anteriormente, o espaço inicial do problema do REST era amplo.

Por mais ampla que fosse, era popular a ideia de usar a Web para o compartilhamento de dados e serviços baseados em rede além do navegador. Os desenvolvedores de software rapidamente aproveitaram o trabalho de Fielding e o colocaram em prática3. A ascensão do REST foi alimentada por uma falsa dicotomia, com o SOAP desempenhando o papel de vilão. Enquanto o SOAP tentou fornecer um método de tunelamento por meio dos protocolos da Web, a abordagem REST os adotou. Essa noção de que o REST é "da Web, não apenas na Web" tornou-a uma opção mais intuitiva para engenheiros de software que já desenvolvem soluções baseadas na web.

À medida que o ecossistema SOAP e WS-* se tornaram mais complicados, a relativa simplicidade e usabilidade do REST foram vencidas. Com o tempo, o JSON substituiu o XML como o formato de dados, de fato, das APIs da web, por motivos semelhantes. À medida que o uso do paradigma da computação na web se expandia para novos cenários, como integração de aplicações corporativas, provisionamento em nuvem, consulta de data warehouse e IoT, também acontecia a adoção de APIs REST.

Porém, se fosse examinado cada cenário de uso específico, poderiam haver alguns pontos fracos na aplicabilidade do REST, ou alguma abordagem de comunicação alternativa que parecesse mais ideal. Mas essa análise ignoraria o poder que vem da universalidade do REST. Devido a onipresença do REST, os desenvolvedores da web, que estavam acostumados a fazer chamadas AJAX, puderam compreender intuitivamente como usar as APIs da AWS para provisionar a infraestrutura de nuvem; os desenvolvedores de redes sociais baseadas na web poderiam estabelecer rapidamente a comunicação para aplicativos móveis; os desenvolvedores corporativos tinham uma maneira bem conhecida de fazer com que os microservices recém-decompostos conversassem entre si. A engenharia de software é um campo em que as barreiras à entrega são geralmente mais humanas que as máquinas. Abordagens bem compreendidas fornecem valor, muitas vezes tendo um impacto maior no tempo de entrega do que soluções de nicho tecnologicamente otimizadas.

Essa universalidade também criou robustez no ecossistema REST. O Swagger - agora OpenAPI - surgiu organicamente como uma especificação de metadados para ajudar os desenvolvedores a documentar, projetar e consumir APIs. O OAuth fornece um framework escalável e transferível para autenticação e autorização4. O "Gerenciamento de APIs" surgiu como um conjunto de recursos: limitação de taxa, roteamento dinâmico e armazenamento em cache, que provaram ser geralmente úteis ao fornecer APIs REST. A abrangência do paradigma REST e a maturidade de seu ecossistema representam o maior valor do REST como uma abordagem à comunicação baseada em rede em um sistema de software. Certamente, essa onipresença vem mais do REST sendo "como a Web funciona" do que de qualquer detalhe técnico.

Comunicação no paradigma pós-web

O impacto da Web na engenharia de software não pode ser exagerado. Paralelamente à ascensão do REST, o mundo da engenharia de software também viu o advento do open source, do Agile, do DevOps, do Domain-Driven Design e da arquitetura de microservice. Cada um desses movimentos foi ativado pela Web e, coletivamente, amplificaram a importância do elemento humano na entrega de software. Juntamente com a flexibilidade e conveniência oferecidas pela computação em nuvem, surgiu um novo paradigma de engenharia de software caracterizado por aplicativos e serviços continuamente em execução, em constante evolução e pouco acoplados. Enquanto Tim Bray chamou em seu artigo de "pós-REST", talvez esse novo paradigma possa ser chamado de "pós-web". E como as características desse paradigma se alinham aos princípios originais do REST de Fielding, não faria sentido descartar o REST e começar do zero. Por outro lado, seria igualmente ingênuo ignorar duas décadas de inovações tecnológicas.

Então, como o valor do REST pode evoluir neste novo paradigma? Há um número crescente de organizações adotando uma abordagem "API First" para o desenvolvimento de software; isto é, enfatizando a importância de projetar as interfaces de máquina em seus aplicativos e serviços na mesma medida que as interfaces de usuário, e usando essas APIs para desacoplar os esforços de desenvolvimento de equipes responsáveis ​​por diferentes domínios. O OpenAPI geralmente desempenha um papel importante nessa metodologia, como a especificação de interface independente de implementação. De acordo com o paradigma pós-Web, isso beneficia as várias pessoas envolvidas na construção ou modificação do sistema de software. Já existe um projeto em andamento - AsyncAPI de Fran Mendez - que visa trazer esse mesmo valor para interações baseadas em eventos. Na mesma linha, Mike Amundsen e Leonard Richardson apresentaram a especificação ALPS para capturar a semântica das interações de aplicativos baseadas em rede. Esforços como esses ajudam a enfrentar os desafios em tempo de desenho da construção de sistemas distribuídos.

Há oportunidades para estender o valor do REST em tempo de execução nativa da nuvem. A mudança para microservices introduziu limites de rede, na qual a comunicação entre processos (IPC) costumava ocorrer. Esses limites físicos podem ser projeções de limites de domínio de negócios pelo desenho, a fim de alcançar os benefícios das pessoas. No entanto, há uma desvantagem implícita no tempo de execução devido a latência de rede adicional e o potencial para falhas parciais na cadeia de chamada dos serviços.

O padrão service mesh endereça esses problemas para sistemas baseados em contêiner, apresentando um proxy de serviço "sidecar" que lida com toda a comunicação baseada em rede entre os componentes da aplicação. A topologia do service mesh significa que o IPC foi reintroduzido entre os contêineres da aplicação e seus sidecars associados. No entanto, os desenvolvedores de contêineres da aplicação ainda precisam especificar protocolos de rede em seus códigos, já que os proxies de serviço normalmente não alteram os protocolos de transporte para mensagens com proxy.

Esses desenvolvedores de aplicações deveriam lidar com o manuseio de protocolos? Em vez disso, eles poderiam lidar com solicitações de serviço abstratas (consultas, comandos, eventos) e fazer com que o proxy de serviço controle o mapeamento de protocolo, a transcodificação e a transmissão? Essas questões devem ser exploradas e o entendimento universal do tempo de design das APIs REST poderia oferecer um ponto de partida para a abstração. Essas são apenas duas áreas em que a onipresença do REST pode ser aproveitada para ajudar a solidificar o paradigma pós-Web.

Um futuro menos RESTless

As impulsionadas tendências tecnológicas costumam mostrar como elas podem substituir a abordagem antiga por uma nova. Na realidade, a evolução na engenharia de software geralmente acontece em camadas. Cada inovação define a base para um novo conjunto de próximas inovações. Novos protocolos de API, como GraphQL, gRPC e Kafka, substituirão o uso de mensagens baseadas em recursos, codificadas em JSON e transmitidas por HTTP em alguns cenários distribuídos. No entanto, o legado do REST na evolução dos sistemas distribuídos deve ser menos sobre seus detalhes de implementação e mais sobre os traços que levaram à sua onipresença: fornecer uma estrutura para conectividade universal, desacoplando os consumidores de serviços dos provedores, enfatizando usabilidade e acessibilidade. São essas características que podem tornar o REST, originalmente definido como o estilo arquitetônico da Web, fundamental para o paradigma pós-Web da engenharia de software.

Notas de rodapé

  1. A intenção deste artigo não é debater a definição de REST. O termo "REST" será usado tanto para se referir à definição original de Fielding quanto às APIs no estilo CRUD sobre HTTP;
  2. Para uma análise prática do contexto de decisão REST/gRPC/GraphQL, leia este post de Phil Sturgeon;
  3. ... e muito anteriormente, o desejo de destinar REST para CRUD sobre HTTP já estava sendo fomentado. Podemos até encontrar perguntas sobre esse assunto;
  4. Voltando à dicotomia com o SOAP, esse desenvolvimento de padrões orgânicos contrasta com a explosão dos padrões W3C e OASIS que apareceram durante o auge do boom de Web Services no início dos anos 2000.

Agradecimentos a Mike Amundsen, Erik Wilde, Irakli Nadareishvili e Ronnie Mitra pela localização dos recursos da "história do REST" listados neste artigo.

Sobre o autor

Matt McLarty é um experiente arquiteto de software que lidera a equipe da API Academy para a CA Technologies, uma empresa da Broadcom. Trabalha em estreita colaboração com organizações no design e implementação de soluções inovadoras de API e microservices em nível corporativo. Matt trabalhou extensivamente no campo de integração e processamento de transações em tempo real para fornecedores de software e clientes. Co-autor do livro O'Reilly Microservice Architecture e Securing Microservice APIs.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT