Para abrir os trabalhos no blog da Mobiliza que trata de desenvolvimento vamos falar de REST e arquitetura de sistemas distribuídos. Esse vai ser o primeiro de uma série que pretende falar de estilos arquiteturais, principalmente REST, e discutir o desenho de APIs bem como especificidades como versionamento, HATEOAS, nomenclatura, documentação e etc.
Por muito tempo se discutiu arquiteturas para sistemas distribuídos, contudo foi com o amadurecimento das aplicações baseadas na web que se tornaram claras as premissas que estas deveriam suprir para fundamentá-las. A arquitetura REST foi sugerida e fundamentada na tese de doutorado de Roy Fielding e que como ele mesmo afirma, se baseou no “sucesso” do HTTP como protocolo web para abstrair várias de suas características em uma arquitetura que giraria em torno das seguintes premissas:
- Escalabilidade: Escabilidade trata da aplicação suportar constante crescimento. Em sua dissertação Roy ainda subdivide este conceito em:
- “scaling up”: Conceito que é conhecido como crescimento horizontal e que trata do crescimento da aplicação e de suas funções, operações e dados;
- “scaling out”: Conceito que é conhecido como crescimento horizontal da aplicação replicando sua execução e dividindo sua carga;
- “smoothing out”: Trabalha em conjunto com o conceito acima e trata do balanceamento de carga entre múltiplos processos e aplicações.
Em uma análise mais crítica podemos dizer que REST pouco ajuda no item 1, scalling up, uma vez que a arquitetura pouco influi em como uma aplicação é estruturada e por conseqüência como será seu crescimento ajudando apenas a torná-lo estruturado e previsível (Interface regular). No que tange ao balanceamento de carga o estilo arquitetural também não impõe ou oferece diretrizes sólidas para esta abordagem, contudo, torna sua implementação facilitada uma vez que prevê um sistema de camadas integrado. O grande foco da arquitetura está na escalabilidade horizontal, onde REST impõe uma arquitetura cliente-servidor assegurando desacoplamento, sem estado e com uma interface regular de comunicação.
- Simplicidade:
Simplicidade foi um dos grandes pontos que chamaram a atenção de Roy para o sucesso do HTTP e como este aspecto garantia a separação de preocupações e o acoplamento dos sistemas distribuídos. Este foi um dos focos da arquitetura e um dos grandes motivos pelo seu atual sucesso principalmente no design de APIs dando sustentação a várias das outras premissas da arquitetura como: visibilidade, confiabilidade e portabilidade.
- Visibilidade:
Visibilidade em REST trata de como os serviços e processos são visíveis e passíveis de mediação entre si. Basicamente, o que Roy descreve aqui é como a arquitetura irá trabalhar com middlewares regulando e monitorando as operações entre as diferentes partes da arquitetura, geralmente como forma de melhorar o controle administrativo sobre toda a aliciação. Esta premissa assim providencia benefícios como:
- Responsabilidade compartilhada sobre cache;
- Auxilia escalabilidade através de camadas de gerenciam requisições diminuindo o impacto nos serviços;
- Auxilia confiabilidade garantindo que uma requisição sempre alcance um serviço disponível;
- Suporta o fortalecimento da segurança inspecionando e filtrando requisições em camadas de segurança de rede e firewalls.
Visibilidade trata de quão genéricas a informação entre as partes é transmitida sem o conhecimento de regras específicas de serviço, assim, ela se relaciona diretamente com a premissa de Interface regular.
- Portabilidade:
Portabilidade trata basicamente da capacidade de deslaçamento de uma ou mais funções ou operações sem prejudicar demais areas do sistema. Esta premissa se relaciona com um tema complexo e bem atual, que é a parte de versionamento de API e serviços REST, que hoje em dia se discute melhores práticas e implementações. Mas como este não é o foco deste artigo vou deixar alguns links de referencia[1].
- Confiabilidade:
Em sua dissertação Roy trata da confiabilidade como capacidade de uma operação ou serviço (e a infra-estrutura que lhe dá suporte) se recuperar de alguma falha. Como vimos na premissa que trata de visibilidade REST em sua definição prevê processos visíveis e principalmente monitoráveis, propiciando o tratamento das falhas de maneira concisa.
- Performance*:
Performance é um termo muito amplo e tem diversas implicações.
Se formos falar de performance em termos de uso de hardware por parte do servidor o estilo arquitetural REST é razoavelmente melhor que suas concorrentes diretas uma vez que se baseia no protocolo HTTP e gera mínimo retrabalho com a informação comunicada.
Falando em performance de banda REST é significativamente melhor uma vez que a informação trafega por HTTP sem nenhuma forma de encapsulamento.
Mas então, por que do asterísco neste termo? Aplicações REST, como vimos, se baseiam em recursos e em suas representações, e assim, qualquer compilação entre dados de recursos distintos, filtragem, ordenação e qualquer outro tipo de tratamento desses recursos deve ser de responsabilidade de uma outra camada.
Por exemplo: se numa comunicação Cliente-Servidor o Cliente precisa de uma listagem de todos os endereços e todos os usuários cadastrados. Em se tratando de recursos distintos o Cliente seria obrigado a fazer duas requisições. Em uma arquitetura baseada em SOAP poderiamos acionar um processo que retornasse a compilação de ambos os dados em uma nova formatação dos dados.
Porém, como também veremos, REST é uma arquitetura que foi pensada para trabalhar em um sistema de camadas, e é comum grandes aplicações criarem o que é chamado de “camada de orquestração”, para afunilar e gerenciar essas chamadas de maneira mais performática. Esse foi o caso do Netflix há alguns anos, quando viram seu público mudar de um grande número de aplicações desconhecidas para um pequeno número de aplicações conhecidas, consumindo dados de sua API e da sua necessidade de transformar a massa de dados generalizada em recursos para uma saída mais específica.
Vamos acabar este primeiro post aqui que ficou bem claro quais as premissas que guiaram Roy Fielding durante toda sua análise de abstração do HTTP para um estilo arquitetural que suprisse todos esses pontos.
Referências:
- https://whatisrest.com/
- https://code.tutsplus.com/tutorials/a-beginners-guide-to-http-and-rest–net-16340
- https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3
[1] Versionamento de APIs:
