Afinal o que são os tão populares RESTful Services? Diante das inúmeras definições e más interpretações difundidas pela comunidade de IT, é fundamental esclarecermos os princípios que norteiam o REST, as suas características e desafios.

REST (REpresentational State Transfer) trata-se de um estilo arquitectural direccionado para sistemas distribuídos e escaláveis, apresentado por Roy Fielding na sua tese de doutorado no ano 2000. Podemos entender por estilo arquitectural uma série de restrições bem definidas (conhecidas como constraints) que delimitam os elementos de uma determinada arquitectura de software e as suas interações.

O estilo REST, portanto, fornece um conjunto de restrições arquitecturais que, quando aplicadas como um todo, potencializam a escalabilidade e o deploy independente dos componentes, a generalidade de interfaces, o encapsulamento de sistemas legacy, além de aprimoramentos na segurança e desempenho. Por esses motivos, o REST (ou pelo menos parte dele) tem sido amplamente adoptado por inúmeras organizações como principal forma de proporcionar acesso aos seus serviços. O site ProgrammableWeb disponibiliza-nos uma breve visão da diversidade de APIs espalhadas pelo mundo que utilizam o REST.

Tal movimento fez com que muitos desenvolvedores passassem a caracterizar as suas APIs baseadas em HTTP de RESTful. Todavia, segundo o próprio Fielding, para que um serviço possa ser chamado de RESTful, este  deve obrigatoriamente cumprir todas as restrições impostas pelo REST e, sobretudo, ser orientado a hipertexto.

Por outro lado, talvez por ainda não existir uma recomendação/padronização oficial da indústria, surgiram diferentes opiniões sobre como se implementar correctamente o estilo e chegar ao glorioso RESTful Service. Diante da inexistência de uma resposta contundente para esta questão, é importante revisitar as principais constraints que devem ser seguidas aquando do desenho e implementação de serviços RESTful:

 

1. Arquitectura Cliente-Servidor: o objectivo principal desta constraint é a separação de responsabilidades. Ao separar os requisitos inerentes à UI, das camadas de negócio e de persistência, aumenta-se a portabilidade, escalabilidade e simplifica a distribuição dos componentes.

2. Stateless: cada requisição feita ao servidor deve conter toda a informação necessária para a correcta execução do pedido. Isto implica que o servidor não deve armazenar nenhum tipo de informação acerca do contexto do cliente para ser utilizado em requisições futuras (e.g., guardar dados da sessão do utilizador). Assim, promovemos a fiabilidade e escalabilidade.

3. Cache: com o intuito de potencializar a reutilização dos dados e melhorar o desempenho do sistema evitando processamentos denecessários, é fundamental que as respostas às requisições possam ser “cacheadas”. Um inconveniente desta restrição é a possível redução da fiabilidade. Por isso, o servidor deve ser capaz de implementar mecanismos eficazes para perceber se um determinado recurso pode ser posto em cache e até quando, para não fornecer informações desactualizadas.

4. Interfaces uniformes: uma das características que diferencia o REST de outros estilos é a ênfase dada na uniformização das interfaces entre componentes. Esta restrição é subdividida em 4 constraints:

– Os recursos devem ser identificáveis. Um conceito elementar do REST são os recursos, os quais podem ser um objecto, uma informação ou qualquer conceito abstracto que possa ser nomeado. O caso mais comum é a utilização de URIs para identificação e localização dos recursos num servidor.

– Os recursos devem ser manipulados através de representações. Uma representação é uma sequência de bytes que determina o estado actual ou pretendido de um recurso. Pode estar na forma de documentos HTML, XML, JSON, CSV, JPEG, etc.

– As mensagens devem ser auto descritivas, isto é, qualquer componente intermediário, (e.g., um proxy), pode interceptar e perceber a semântica da mensagem trocada. No âmbito do HTTP, podemos exemplificar o uso correcto dos métodos, dos status codes e metadados (e.g., parâmetros do header). É importante frisar que os métodos de requisição (GET, POST, PATCH, etc.) não fazem parte do estilo arquitectural, mas sim do protocolo HTTP.

– A hipermídia deve ser o motor do estado da aplicação. Mais conhecido como HATEOAS (Hypermedia As The Engine Of Application State), esta restrição suporta não apenas a descoberta e manipulação de novos recursos de modo a reduzir o acoplamento, mas também promove a auto documentação. A ideia geral é que o cliente, na posse de um recurso, possa determinar as suas acções subsequentes consoante o controlo de hipermídia apropriado (e.g., por meio de links). A imagem abaixo ilustra um exemplo (a vermelho) da aplicação do HATEOAS.

 

 

5. Sistema em camadas: o objectivo desta constraint é alcançar requisitos de alta escalabilidade, permitindo que os clientes não comuniquem directamente com os servidores, mas sim com intermediários. Exemplos disso são os Load Balancers, Proxies e Cache Servers. O inconveniente desta restrição assenta-se no possível aumento de latência na rede, onde mais comunicações são necessárias na medida em que novas camadas são adicionadas.

6. Código sob demanda: permite que as funcionalidades do cliente sejam extensíveis por meio da provisão e execução de códigos sob demanda, na forma de applets ou scripts, por exemplo. No entanto, como nem todos os serviços ou consumidores podem executar código sob demanda, seja por limitações no âmbito do negócio ou restrições de segurança, esta constraint é considerada opcional, dando mais poder e flexibilidade ao estilo.

 

Como pode ser visto, há muito mais no REST do que apenas o uso de representações JSON ou dos métodos HTTP. Por sinal, o JSON nem sequer é mencionado na tese de Fielding. Documentos HTML e imagens JPEG foram utilizados na altura para exemplificar as representações de recursos. O HTTP tão pouco é uma restrição do estilo, deixando-nos livres para utilizar qualquer outro protocolo de transferência.

Com esta imensidão de interpretações acerca do REST, vale a pena mencionar o nome de Leonard Richardson, que propôs um modelo de maturidade para facilitar a implementação de serviços HTTP em direção à “glória” do REST.

 

O nível mais baixo consiste basicamente na utilização do protocolo HTTP, para transporte da informação em POX (Plain Old XML). Já o nível 1 visa a quebra do serviço em endpoints menores que oferecem diferentes recursos. O nível 2 introduz um conjunto de operações que nos permitem manipular os recursos por meio de métodos (verbos) já existentes no HTTP. Por fim, o último nível de maturidade requer a aplicação do HATEOAS.

Existe ainda um modelo mais abrangente (Classification of HTTP-based APIs) que considera os serviços SOAP – os quais são também implementados sobre o HTTP, a despeito de utilizarem maioritariamente o método POST nas requisições e o XML como representação. É neste ponto que reside uma das principais diferenças entre o REST e o SOAP: enquanto que o primeiro é um estilo arquitectural, o segundo é um protocolo que define precisamente como as mensagens/recursos devem ser representadas. As vantagens e inconvenientes de cada abordagem ficam para um próximo post.

Resumindo, este artigo pretende mostrar como o estilo arquitectural REST impõe certas restrições que tornam os serviços genuinamente RESTful. Contudo, é comum que alguns desenvolvedores não respeitem um subconjunto destas restrições. Nesses casos, o mais coerente seria, quiçá, denominar tais implementações de REST-based Services, em vez de RESTful.

Como perspectivas futuras, é possível notar uma continuidade e evolução na adopção do REST, a exemplo de iniciativas como o Open Banking, Government Digital Service, Open API, Open Data Protocol, entre outras. Adicionalmente, algumas tecnologias, como o GraphQL, têm sido difundidas com o intuito de aprimorar algumas deficiências existentes no REST. Além disso, APIs semânticas que utilizam ontologias para fornecer dados conectados – já publicadas por algumas entidades governamentais do UK, por exemplo – têm fomentado o uso de consultas via SPARQL e a execução de análises de dados mais sofisticadas, automatizando processos de descoberta e composição de serviços baseados em REST.

 

Bruno Oliveira – Software Engineer

Prime Solutions