Restrições arquitetónicas da API REST

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 que sejam lidos e processados com um protocolo sem estado. As operações que um cliente pode realizar são predefinidas e bem conhecidas, geralmente baseadas nos protocolos HTTP.

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

São muitos benefícios, mas como é que as APIs REST os alcançam, poderá perguntar? Simples, seguindo seis restrições. Na verdade, estas regras são as características mais marcantes do estilo arquitetónico RESTful.

A função de uma API é conectar dois softwares sem limitar as suas próprias funcionalidades. Este objetivo é uma das restrições centrais do REST: o cliente (que faz as solicitações) e o servidor (que fornece as respostas) permanecem separados e independentes.

Quando feito corretamente, o cliente e o servidor podem atualizar-se e evoluir em direções diferentes sem que isso tenha impacto na qualidade da troca de dados entre eles. Isto é especialmente importante em vários casos em que um servidor tem de atender a muitos clientes diferentes. Pense nas APIs meteorológicas — elas têm de enviar dados para inúmeros clientes diferentes (todos os tipos de dispositivos móveis são bons exemplos) a partir de uma única base de dados.

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

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

No mesmo caso, uma API sem estado garantirá que cada chamada contenha a chave da API e que o servidor espere ver uma prova de acesso em cada ocasião.

As APIs sem estado têm a vantagem de que uma chamada incorreta ou com falha não prejudica as que se seguem.

Embora o cliente e o servidor mudem de formas diferentes, é importante que a API continue a facilitar a comunicação. Para tal, as APIs REST impõem uma interface uniforme que pode facilmente acomodar todo o software ligado.

Na maioria dos casos, essa interface baseia-se nos protocolos HTTP. Além de estabelecer regras sobre como os clientes e o servidor podem interagir, tem também a vantagem de ser amplamente conhecida e utilizada na Internet. Os dados são armazenados e trocados através de ficheiros JSON devido à sua versatilidade.

Para manter a API fácil de compreender e escalar, a arquitetura RESTful determina que o design seja estruturado em camadas que operam 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 seguinte. As camadas conectadas 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, é possível adicionar, modificar ou remover camadas sem comprometer outros componentes da interface.

Não é raro que as solicitações de uma API sem estado tenham uma sobrecarga significativa. Em alguns casos, isso é inevitável, mas para solicitações repetidas que necessitam dos mesmos dados, armazenar essas informações em cache pode fazer uma enorme diferença.

O conceito é simples: o cliente tem a opção de armazenar localmente certos dados por um período de tempo predeterminado. Quando faz uma solicitação desses dados, em vez de o servidor enviá-los novamente, utiliza a versão armazenada.

O resultado é simples: em vez de o cliente enviar várias solicitações complexas ou dispendiosas num curto espaço de tempo, só precisa de o fazer uma vez.

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

O conceito consiste em permitir que código ou applets sejam enviados através da API e utilizados pela aplicação. Como se pode imaginar, código desconhecido proveniente de uma fonte duvidosa pode causar danos, pelo que é melhor reservar esta restrição para APIs internas, onde há 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 adequada para a aplicação, o que nem sempre é o caso.

A vantagem é que o “código sob demanda” pode ajudar o cliente a implementar as suas próprias funcionalidades em tempo real, com menos trabalho necessário na API ou no servidor. Em essência, permite que todo o sistema seja muito mais escalável e ágil.

O foco do design RESTful está na eficiência e escalabilidade num mundo dominado pela web. Como se pode imaginar, isto tornou a arquitetura bastante popular, e é muito provável que a vejamos tornar-se ainda mais difundida nos próximos anos.

A principal preocupação de muitos programadores e especialistas em segurança é o quão vulneráveis as APIs web podem ser 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 é como se fôssemos deixar 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 proxies até à renderização de Javascript e à resolução de CAPTCHAs. Confira para ver o que uma API REST pode fazer!