Saiba projetar APIs confiáveis e robustas

Por quase 20 anos, RESTful foi considerado um padrão comum de APIs. Ao mesmo tempo em que foi promovido, tal padrão também foi considerado por alguns especialistas como “morto”. 

À medida que o debate sobre sua eficácia atual ainda permanece, outra abordagem vem se tornando relevante para as APIs, aquela baseada em eventos, a API EVENTful. E já existem empresas que misturam práticas RESTful e EVENTful em seus designs de API, sendo que na maioria das vezes, uma única definição de serviço conterá os dois estilos. 

A estabilidade do REST síncrono   

A palavra “RESTful” consegue abarcar uma quantidade significativa de designs, dentre eles o mais comum é o padrão CRUD (Criar-Ler-Atualizar-Excluir) popularizado no livro “ RESTful Web Services” de Leonard Richardson. Entretanto, há outras versões comuns de RESTful como REST hipermídia da API AppStream da Amazon e soluções como “long polling” sobre HTTP. 

Todas essas abordagens acima são síncronas, ou seja, há uma ordem sequencial fixa para a maneira como os dados são enviados e recebidos. 

Mesmo que serviços RESTful funcionem bem para recursos orientados a documentos e granulados voltados para navegadores da web comuns, há uma alta demanda por serviços interativos em tempo real gerada, demanda gerada pela explosão do mercado de dispositivos “inteligentes”. 

E é aqui que uma abordagem EVENTful entre em cena. 

A flexibilidade de eventos assíncronos  

Se por um lado sistemas RESTful se concentram em recursos, as soluções EVENTful são voltadas para ações e contam com interações assíncronas. Isso abre um leque de novas possibilidades para desenvolver soluções responsivas em tempo real. 

Dessa forma, um design EVENTful permite que serviços solicitem e respondam em tempo real. O resultado é uma maior flexibilidade no modo como os dados são compartilhados, exibidos e combinados entre dispositivos e plataformas. 

Um padrão que a maior parte das pessoas relaciona ao design EVENTful é conhecido por Event Sourcing (ES). No cenário do ES todo 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. 

Alguns exemplos de abordagem EVENTful são web hooks, publish-subscribe e command-query responsibility separation (CQRS). O elemento comum em todos a confiança em interações assíncronas - o desacoplamento das solicitações e respostas - que leva a outra expressão comum: consistência eventual. 

Ao passo que o uso de microsserviços nas empresas aumenta, há uma chance de que que o número de interações EVENTful também cresça.  

Normalmente, microsserviços são melhores no dimensionamento e na recuperação se temos interações assíncronas envolvidas. Contudo, isso não implica que eles sejam fáceis de projetar e gerenciar. E é importante ter isso em mente se sua companhia deseja adicionar mais eventos em tempo real, pois no fim das contas, será necessário aprender como projetar, construir e gerenciar serviços assíncronos e APIs.  

Vale destacar que o crescimento nos padrões EVENTful não significa voltar atrás em seu trabalho RESTful. Ao que tudo indica, as empresas estão adicionando soluções EVENTful, ao mesmo tempo em que ainda investem nas interações RESTful e síncronas. Logo, a solução mais popular é na verdade fornecer RESTful e EVENTful em terminais diferentes dentro do mesmo serviço.  

O bom design de API 

Cada vez mais as APIs estão transformando o mundo dos negócios. É preciso cuidado e atenção ao seu design, desde a prototipagem e implementação até a implantação das mesmas. 

Um bom design de API implica no princípio de API-First, ou seja, compreender quem está usando a API e o que será feito com ela, para assim aplicar habilidades básicas de design e atender às necessidades dos clientes enquanto resolve problemas críticos de negócios. 

Em breve a segunda parte da série “Saiba como projetar APIs robustas e confiáveis”  e para mais detalhes sobre o Design de APIs veja meu livro “Design and Build Great Web APIs: Robust, Reliable, and Resilient” 

Este artigo foi escrito por Mike Amundsen e publicado originalmente em Prensa.li.