O que é uma API REST?

Uma API REST é um tipo de interface de programação de aplicações (API) que segue o modelo de transferência de estado representacional (REST) para representação de dados e comunicação entre dois sistemas (um cliente e um servidor) por meio de uma rede, como a Internet. As APIs REST permitem a troca de informações entre aplicações internas e de terceiros, além de possibilitar que as empresas integrem vários endpoints ao ecossistema de suas aplicações.

Observação: A rigor, REST refere-se ao modelo e não é um adjetivo que designe uma API que o siga, para a qual o termo correto é API RESTful. No entanto, API REST é a forma mais comum e, portanto, é a utilizada neste artigo.

O que é REST?

REST, que, como mencionado, significa transferência de estado representacional, é um estilo arquitetural criado pelo cientista da computação Roy Fielding em 2000. O REST oferece flexibilidade aos desenvolvedores, o que o torna ideal para conectar aplicações em arquiteturas de microsserviços.

O REST define seis restrições que aplicativos e APIs devem seguir para serem considerados RESTful:

• Interface uniforme
• Arquitetura cliente-servidor
• Ausência de estado
• Sistema em camadas
• Capacidade de armazenamento em cache
• Código sob demanda

Você pode saber mais sobre essas restrições na Wikipédia.

Interface uniforme

Uma interface uniforme simplifica a arquitetura geral do sistema e melhora a visibilidade das interações. Ela também possui requisitos específicos para garantir que as informações sejam transferidas de forma padronizada.

Quatro restrições permitem que uma interface REST seja uniforme:

• Cada recurso tem um identificador exclusivo, como um URI, e a representação do recurso em uma mensagem é distinta da representação interna do servidor
• A representação do recurso inclui informações suficientes para que o cliente modifique ou exclua o estado de um recurso
• Cada mensagem inclui informações suficientes para descrever como processá-la
• O servidor usa hiperlinks para informar os clientes sobre os recursos disponíveis, eliminando a necessidade de os clientes conhecerem os detalhes internos do servidor

Cliente-Servidor

Uma arquitetura cliente-servidor é composta por clientes, servidores e recursos. Separar a interface do usuário (controlada pelo cliente) do armazenamento de dados (controlado pelo servidor) permite que os componentes do cliente e do servidor evoluam de forma independente. Isso também facilita a portabilidade da interface do usuário do cliente entre várias plataformas e a escalabilidade do servidor.

Na Internet, a interação cliente-servidor ocorre por meio de HTTP.

Ausência de estado

Na comunicação cliente-servidor, a ausência de estado significa que o servidor não armazena nenhuma informação sobre o cliente nem sobre a sessão estabelecida com ele. A representação das informações relacionadas à sessão enviada pelo cliente em cada mensagem deve permitir que o servidor a compreenda de forma isolada, sem nenhum contexto de mensagens anteriores. Isso reduz a carga do servidor, melhorando o desempenho de aplicações com alto volume de tráfego.

Sistema em camadas

Os clientes não precisam saber (e geralmente não conseguem identificar) se estão conectados diretamente ao servidor ou a um intermediário, como um proxy reverso ou balanceador de carga. Os servidores intermediários ajudam a melhorar a escalabilidade e podem ser usados para cuidar da segurança, permitindo que os servidores sejam responsáveis apenas pela lógica de negócios.

Capacidade de armazenamento em cache

Clientes HTTP e intermediários podem armazenar em cache as respostas do servidor para reduzir a carga sobre ele e aumentar a velocidade de entrega de dados aos usuários finais. O servidor deve indicar se uma resposta pode ou não ser armazenada em cache. Nesse último caso, isso garante que as respostas às solicitações subsequentes dos usuários finais estejam corretas e atualizadas (e não potencialmente “obsoletas”). Como os clientes acessam um recurso por meio de sua URL, que é um identificador exclusivo, eles podem determinar o que armazenar em cache no nível do recurso.

Código sob demanda

Code-on-demand significa que o servidor pode enviar código executável para estender ou personalizar temporariamente a funcionalidade do cliente, eliminando a necessidade de o próprio cliente implementá-la. A restrição de code-on-demand é opcional.

O que é um recurso?

A representação ou abstração de dados mais importante em REST é um recurso. Um recurso REST pode ser qualquer tipo de informação abstraída — desde um documento digital até um objeto não digital. O estado do recurso em um determinado momento é chamado de representação do recurso.

Uma representação de recurso tem três partes:

• Dados
• Metadados
• Links de hipermídia

Uma API REST consiste em um conjunto de recursos interligados (ou seu modelo de recursos ) que podem ser acessados por URIs exclusivos. Um cliente pode obter funcionalidades flexíveis por meio de links para recursos e URIs relacionados na resposta. Em geral, uma solicitação a uma API REST é enviada na forma de uma solicitação HTTP GET; os servidores geralmente formatam suas respostas como JSON.

Os seguintes métodos de requisição HTTP são usados para realizar as ações indicadas nos recursos:

• GET – Carregar um recurso
• POST – Criar um novo recurso
• PUT – Modificar um recurso existente
• DELETE – Remover um recurso

Identificador do recurso

Nos estilos arquiteturais REST, os identificadores de recursos designam de forma exclusiva cada recurso envolvido nas interações entre cliente e servidor.

Hipermídia

Um “tipo de mídia”, ou representação do formato de dados, define como um recurso deve ser processado. Em APIs REST, todos os tipos de mídia são baseados em JSON e são hipermídia (às vezes conhecida como hipertexto, embora seja ligeiramente diferente). Hipermídia é qualquer conteúdo que contenha links para outras mídias. Hipermídia como Motor do Estado da Aplicação (HATEOAS) é o que torna a arquitetura REST única.

Observação: de acordo com Roy Fielding, para que uma API seja considerada uma API REST, ela deve usar hipermídia. No entanto, muitos projetistas de APIs hoje chamam suas APIs de “REST[ful]” apenas por ser um termo da moda, embora não usem hipermídia/hipertexto.

Autodescritivo

As representações de recursos buscam ser autodescritivas, o que significa que a API se faz entender dentro do próprio contexto. Com representações autodescritivas, o cliente não precisa saber a qual categoria um recurso pertence; em vez disso, ele age com base no tipo de mídia associado ao recurso.

Benefícios das APIs REST

Atualmente, a maioria das empresas usa APIs desenvolvidas internamente e APIs de terceiros para a comunicação entre aplicativos que oferecem funcionalidades básicas, inovadoras e essenciais. A maioria dessas APIs é do tipo REST, pois os padrões específicos de comunicação definidos pelo REST permitem a troca de informações de forma segura, eficiente e confiável. As APIs REST também podem funcionar com qualquer protocolo.

As APIs REST também são seguras porque o serviço web RESTful autentica as solicitações antes de enviar uma resposta. Para verificar a identidade dos usuários, as APIs REST utilizam autenticação HTTP (tanto Básica quanto por Token Bearer), chaves de API e OAuth para acesso por login.

Outros benefícios das APIs REST incluem:

• Escalabilidade do sistema – As APIs REST podem ser dimensionadas com eficiência porque o REST otimiza as interações entre cliente e servidor. A restrição de ausência de estado do REST reduz a carga do servidor, pois ele não precisa armazenar informações de solicitações anteriores nem sobre elas. Além disso, a capacidade de armazenamento em cache reduz o número de interações entre cliente e servidor que poderiam criar gargalos. Isso resulta em APIs escaláveis e de alto desempenho.
• Flexibilidade para desenvolvedores – Muitas aplicações empresariais precisam se comunicar com APIs internas ou de terceiros. Os serviços web RESTful permitem a separação entre cliente e servidor, possibilitando que cada um evolua de forma independente.
• Independência tecnológica – As APIs REST permanecem independentes da linguagem de programação e do framework usados no desenvolvimento dos aplicativos correspondentes. Os aplicativos cliente e servidor não precisam usar a mesma linguagem ou o mesmo framework, e esses elementos podem ser alterados sem afetar o design da API nem o processo de comunicação.

APIs REST vs. GraphQL

Embora REST continue sendo a arquitetura mais popular para conectar aplicações cliente e servidor, GraphQL (desenvolvido pelo Facebook em 2012 e disponibilizado como código aberto em 2015) foi projetado como uma alternativa ao REST. As APIs GraphQL são mais eficientes do que as APIs REST porque todos os dados necessários são solicitados em uma única requisição e em um formato padronizado, mas ainda há algumas áreas em que REST se destaca. GraphQL exige uma curva de aprendizado acentuada e oferece muito menos possibilidades de armazenamento em cache do que REST. Além disso, as aplicações geralmente são orientadas a recursos e não precisam de uma linguagem de consulta como GraphQL. Dito isso, cada modelo tem seus prós e contras, e as organizações podem optar por usar ambos.

Como o NGINX pode ajudar?

A flexibilidade das APIs REST é certamente uma vantagem. No entanto, flexibilidade em excesso também pode levar ao desenvolvimento de uma API potencialmente lenta ou com falhas. Por isso, muitos desenvolvedores optam por publicar, gerenciar e gerar a documentação das APIs usando a Especificação OpenAPI.

API Connectivity Manager, parte do F5 NGINX Management Suite, oferece suporte à especificação OpenAPI para APIs REST. O API Connectivity Manager foi projetado tendo como foco a experiência do desenvolvedor de APIs. É uma solução leve e nativa da nuvem para gerenciamento de APIs, com integração perfeita para a publicação de APIs no portal do desenvolvedor e no gateway de API.

Comece uma avaliação gratuita de 30 dias do NGINX Management Suite, que inclui o API Connectivity Manager e o Instance Manager.