Restrições arquitecturais da API Rest

Sorin-Gabriel Marica em Dec 08 2022

As APIs existem em muitas formas e tamanhos. Embora muitos programadores tenham de agradecer às APIs por tornarem o seu trabalho mais fácil de gerir de centenas de formas diferentes, poucos dedicam tempo a aprender mais sobre estas interfaces.

Nós entendemos. O tempo é limitado, e entender o que define uma API REST pode não ser útil para todos. Não vamos negar isso, mas há uma razão pela qual qualquer pessoa deveria aprender isso: é muito interessante. Além disso, se quiser conceber ou trabalhar com uma API, vale a pena saber mais sobre ela.

Portanto, neste artigo, vamos dar uma olhada nos bastidores das APIs REST e entender como seus princípios de design as tornaram o software estável que são hoje.

O que significa ser RESTful

A famosa abreviatura significa "Representational State Transfer", que é um estilo de arquitetura de software. A sua utilização mais comum é facilitar a utilização de serviços Web com uma abordagem padronizada e universal.

Estes serviços Web oferecem os seus recursos Web numa representação textual e permitem a sua leitura e processamento com um protocolo sem estado. As operações que um cliente pode efetuar são predefinidas e bem conhecidas, geralmente baseadas nos protocolos HTTP.

As APIs e o software RESTful não se baseiam num avanço tecnológico ou de programação. Nem sequer são assim tão recentes, tendo sido pensados pela primeira vez em 2000. A ideia por detrás do REST é impor certas regras à API para que se obtenha mais desempenho, escalabilidade, simplicidade, modificabilidade, visibilidade, portabilidade e fiabilidade.

São muitos os benefícios, mas como é que as API REST os alcançam, pode perguntar? Simples, seguindo seis restrições. De facto, estas regras são as caraterísticas que mais definem o estilo arquitetónico RESTful.

As seis restrições arquitectónicas das API REST

1. Arquitetura cliente-servidor

A função de uma API é ligar duas partes de software sem limitar as suas próprias funcionalidades. Este objetivo é uma das principais restrições do REST: o cliente (que faz pedidos) e o servidor (que dá respostas) permanecem separados e independentes.

Quando bem feito, o cliente e o servidor podem atualizar-se e evoluir em direcções diferentes sem ter impacto na qualidade do seu intercâmbio de dados. Isto é especialmente importante em vários casos em que há muitos clientes diferentes a que um servidor tem de dar resposta. Pense nas APIs meteorológicas - têm de enviar dados para toneladas de clientes diferentes (todos os tipos de dispositivos móveis são bons exemplos) a partir de uma única base de dados.

2. Apatridia

Para que uma API seja stateless, tem de tratar as chamadas independentemente umas das outras. Cada chamada à API tem de conter os dados e comandos necessários para completar a ação desejada.

Um exemplo de uma API sem estado seria se, durante uma sessão, apenas a primeira chamada tivesse de conter a chave da API, que é depois armazenada no lado do servidor. As chamadas seguintes à API dependem dessa primeira, uma vez que fornece as credenciais do cliente.

No mesmo caso, uma API sem estado garantirá que cada chamada contém a chave da API e o servidor espera ver a prova de acesso de cada vez.

As APIs sem estado têm a vantagem de que uma chamada má ou falhada não prejudica as seguintes.

3. Interface uniforme

Embora o cliente e o servidor mudem de maneiras diferentes, é importante que a API ainda possa facilitar a comunicação. Para esse efeito, as API REST impõem uma interface uniforme que pode facilmente acomodar todo o software ligado.

Na maioria dos casos, essa interface é baseada nos protocolos HTTP. Para além de estabelecer regras sobre a forma como os clientes e o servidor podem interagir, tem também a vantagem de ser amplamente conhecido e utilizado na Internet. Os dados são armazenados e trocados através de ficheiros JSON devido à sua versatilidade.

4. Sistema em camadas

Para manter a API fácil de compreender e escalar, a arquitetura RESTful determina que o design seja estruturado em camadas que funcionam em conjunto.

Com uma hierarquia clara para estas camadas, a execução de um comando significa que cada camada desempenha a sua função e, em seguida, envia os dados para a camada seguinte. As camadas ligadas comunicam entre si, mas não com todos os componentes do programa. Desta forma, a segurança geral da API também é melhorada.

Se o âmbito da API mudar, as camadas podem ser adicionadas, modificadas ou retiradas sem comprometer outros componentes da interface.

5. Capacidade de armazenamento em cache

Não é incomum que os pedidos de uma API sem estado tenham uma grande sobrecarga. Em alguns casos, isso é inevitável, mas para pedidos repetidos que precisam dos mesmos dados, o armazenamento em cache dessas informações pode fazer uma grande diferença.

O conceito é simples: o cliente tem a opção de armazenar localmente determinados dados durante um período de tempo pré-determinado. Quando faz um pedido desses dados, em vez de o servidor os enviar novamente, utiliza a versão armazenada.

O resultado é simples: em vez de o cliente enviar vários pedidos difíceis ou dispendiosos num curto espaço de tempo, só tem de o fazer uma vez.

6. Código a pedido

Ao contrário das outras restrições de que falámos até agora, a última é opcional. A razão para tornar o "código a pedido" opcional é simples: pode ser um grande risco de segurança.

O conceito é permitir que código ou applets sejam enviados através da API e utilizados para a aplicação. Como pode imaginar, um código desconhecido de uma fonte duvidosa pode causar alguns danos, pelo que é melhor deixar esta restrição para APIs internas, onde tem menos receio de hackers e pessoas com más intenções. Outra desvantagem é que o código tem de estar na linguagem de programação apropriada para a aplicação, o que nem sempre é o caso.

A vantagem é que o "código a pedido" pode ajudar o cliente a implementar as suas próprias funcionalidades em movimento, com menos trabalho a ser necessário na API ou no servidor. Essencialmente, permite que todo o sistema seja muito mais escalável e ágil.

As API REST são o caminho do futuro?

O foco do design RESTful é a eficiência e a escalabilidade num mundo dominado pela Web. Como se pode imaginar, este facto tornou a arquitetura bastante popular e é muito provável que se generalize ainda mais nos próximos anos.

A principal preocupação de muitos programadores e especialistas em segurança é a forma como as API da Web podem ser exploradas se forem criadas sem o devido cuidado. É claro que os hackers têm sido e continuarão a ser um problema para as APIs e para o software em geral. Ainda assim, não é que deixemos de as utilizar. Em vez disso, cabe aos especialistas em segurança encontrar novas formas de proteger os nossos programas.

Essa forma de pensar, juntamente com o objetivo de facilitar a vida dos programadores, foi o que nos levou a desenvolver a WebScrapingAPI, uma API REST de extração de dados que trata de tudo, desde a rotação de proxy à renderização de Javascript e resolução de CAPTCHAs. Veja o que uma API REST pode fazer!