Mudando de RESTful para EVENTful

Mudando de RESTful para EVENTful

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


Por quase vinte anos, o “padrão comum” de APIs na web foi resumido em uma palavra: “RESTful.” Designers, desenvolvedores e arquitetos de software promoveram, debateram e ridicularizaram a noção de APIs RESTful em ondas sucessivas ao longo dos anos, com todos os tipos de especialistas declarando REST “morto” e oferecendo alguma outra prática atual como “o novo REST” ou, até mesmo, melhor, “o assassino REST”. Provavelmente, minha réplica favorita neste espaço é “Overcoming RESTlessness” de Matt McLarty.

À medida que o debate REST continua, outra abordagem importante continuou a se tornar mais comum e, eu acho, mais relevante para APIs hoje – aquela baseada em eventos ou, como gosto de chamá-los, designs de API EVENTful. Em minhas visitas a empresas ao redor do mundo, quase todas estão trabalhando para adicionar serviços EVENTful ao seu ecossistema de API. E existem algumas variações sobre o que significa EVENTful. Artigo de Martin Fowler de 2017 “O que você quer dizer com orientado a eventos?” é uma introdução sólida ao espaço EVENTful.

Vejo algumas empresas misturando práticas RESTful e EVENTful em seus designs de API. Muitas vezes, uma única definição de serviço conterá os dois estilos. O processo “Microservice Canvas” documentado por Matt McLarty e Irakli Nadareshvili torna esta combinação de RESTful e EVENTful clara e fácil ao criar serviços.

A estabilidade do REST síncrono

A palavra “RESTful” cobre uma gama relativamente ampla de opções de design. O mais comum é o padrão CRUD (Creat-Read-Update-Delete) popularizado no livro “RESTful Web Services” de Leonard Richardson. No entanto, existem outras versões de “RESTful” em uso comum. Existe o REST hipermídia da API AppStream da Amazon e soluções como “long polling” (consulte BOSH) sobre HTTP. Todas essas abordagens são síncronas – há uma ordem sequencial fixa para a maneira como os dados são enviados e recebidos.

Uma das grandes vantagens do estilo REST de Fielding é que ele se concentra na criação de uma base estável para expor um amplo conjunto de recursos. O foco da REST em usar o protocolo HTTP para publicar recursos usando URLs exclusivos é o motivo pelo qual a web em geral tem tido tanto sucesso nas últimas décadas.

Empresas, grandes e pequenas, têm copiado a abordagem do Google, Yahoo e outros na construção de seu próprio catálogo de recursos e URLs usando linguagens de definição como OpenAPI. Isso resultou em uma série de produtos e serviços centrados em nuvem baseados em API de sucesso, como Salesforce, Twilio, Google Maps e muito mais.

No entanto, embora os serviços RESTful funcionem bem para recursos orientados a documentos e de grande granularidade voltados para navegadores da web comuns, eles têm lutado para acompanhar não apenas a velocidade da mudança, mas também a demanda por serviços interativos em tempo real gerada por telefones celulares e a explosão do mercado de dispositivos “inteligentes”.

E é aqui que uma abordagem EVENTful pode ser mais eficaz.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

A flexibilidade de eventos assíncronos

Enquanto os sistemas RESTful se concentram em recursos, as soluções EVENTful se concentram em ações. E, mais importante, as soluções EVENTful dependem de interações assíncronas. Isso abre muito mais possibilidades para a construção de soluções responsivas em tempo real. Isso significa que um design EVENTful oferece aos serviços a capacidade de solicitar e responder em tempo real e de fazer isso de uma forma que forneça mais flexibilidade na forma como os dados são compartilhados, exibidos e combinados entre dispositivos e plataformas.

Existem muitos padrões de implementação que se enquadram no guarda-chuva EVENTful. O mais simples é a notificação de evento – obter um “ping” quando algo acontece (por exemplo, “um usuário atualizou seu registro”). Um padrão semelhante é o estado realizado por evento ou ECS. Nesta abordagem, os dados reais relacionados são “carregados” junto com o alerta (por exemplo, “um usuário atualizou seu registro. Aqui está o objeto do usuário …”).

O padrão que a maioria das pessoas associam ao design EVENTful atualmente é comumente chamado de sourcing de eventos ou ES. No mundo ES, cada evento é expresso como uma transação que é enviada a qualquer interessado e também é registrado em uma espécie de “razão” que contém todas as transações do evento. No caso das informações do usuário que estamos discutindo, haveria uma transação que indica a alteração dos dados em cada um dos campos do registro do usuário. Na verdade, isso pode ser expresso como várias transações. Um dos aspectos exclusivos do ES é que quase todas as transações que mudam de estado podem ser “revertidas” com outra transação. Isso geralmente é equiparado aos livros-razão básicos de contabilidade, em que os débitos podem cancelar os créditos no livro-razão.

Existem outras abordagens EVENTful como web hooks, publicação-assinatura e separação de responsabilidade de consulta de comando (CQRS). O elemento mais comum em todos esses padrões é a dependência de interações assíncronas – o desacoplamento das solicitações e respostas – que leva a outra expressão comum: consistência eventual.

A propagação dessas mensagens de transação pode levar algum tempo e vários “livros” podem não ser cópias exatas uns dos outros em diferentes momentos. No entanto, eventualmente, esses vários centros de armazenamento serão consistentes entre si. A consistência eventual é um recurso dos sistemas assíncronos que os ajuda a escalar melhor à medida que seu sistema e volume aumentam.

Resumo

Conforme o número de microsserviços em uma organização aumenta, há uma probabilidade de que o número de interações EVENTful também aumente. Os microsserviços costumam ser melhores no dimensionamento e na recuperação quando há interações assíncronas envolvidas. Eles não são mais fáceis de projetar e gerenciar, no entanto. E essa é uma conclusão importante. Se sua organização está procurando adicionar mais eventos em tempo real, você precisará aprender a projetar, construir e gerenciar serviços assíncronos e APIs.

Obviamente, esse aumento nos padrões EVENTful não significa que você precisa voltar atrás em seu trabalho RESTful. Ao que tudo indica, as empresas estão adicionando soluções EVENTful, mesmo enquanto continuam a impulsionar seus investimentos em interações RESTful e síncronas. Na verdade, uma abordagem popular é fornecer RESTful e EVENTful em terminais diferentes dentro do mesmo serviço. Por exemplo, APIs podem suportar HTTP POST para criar novos registros e também suportar um evento “RecordCreated” que dispara assim que a ação POST é concluída.

Pense nos padrões EVENTful como mais ferramentas em seu kit enquanto você trabalha para projetar e construir excelentes APIs para seus clientes.

Para ver como o MuleSoft oferece suporte a padrões orientados a eventos usando um mecanismo reativo, verifique nosso mecanismo de tempo de execução Mule.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso