Uma API REST é um tipo de interface de programação de aplicativos (API) que está em conformidade com o modelo de transferência de estado representacional (REST) de representação de dados e comunicação entre dois sistemas (um cliente e um servidor) em uma rede como a Internet. As APIs REST oferecem suporte à troca de informações entre aplicativos internos e de terceiros e permitem que as empresas integrem vários endpoints em seu ecossistema de aplicativos.
Observação: A rigor, REST se refere ao modelo e não é um adjetivo que designa uma API que adere a ele, para o qual o termo apropriado é RESTful API . No entanto, REST API é o uso mais comum e, consequentemente, é usado neste artigo.
REST, que como mencionado significa transferência de estado representacional , é um estilo arquitetônico criado pelo cientista da computação Roy Fielding em 2000. REST oferece flexibilidade para desenvolvedores, o que o torna ideal para conectar aplicativos em arquiteturas de microsserviços .
REST define seis restrições que aplicativos e APIs devem obedecer para serem considerados RESTful:
Você pode aprender mais sobre essas restrições na Wikipedia .
Uma interface uniforme simplifica a arquitetura geral do sistema e melhora a visibilidade da interação. Ele também tem requisitos específicos para garantir que as informações sejam transferidas em um formato padrão.
Quatro restrições permitem que uma interface REST seja uniforme:
Uma arquitetura cliente-servidor é composta de clientes, servidores e recursos. Separar a interface do usuário (controlada pelo cliente) do armazenamento de dados (controlado pelo servidor) significa que os componentes do cliente e do servidor podem evoluir de forma autônoma. Ele também simplifica a portabilidade da interface do usuário do cliente em diversas plataformas e a escalabilidade do servidor.
Na Internet, a interação cliente-servidor ocorre via HTTP.
Na comunicação cliente-servidor, a ausência de estado significa que o servidor não armazena nenhuma informação sobre o cliente ou a sessão estabelecida com ele. A representação do cliente das informações relacionadas à sessão em cada mensagem deve permitir que o servidor as entenda isoladamente, sem qualquer contexto de mensagens anteriores. Isso reduz a carga do servidor, melhorando o desempenho de aplicativos de alto volume.
Os clientes não precisam saber (e geralmente não conseguem dizer) se estão conectados diretamente ao servidor ou a um intermediário, como um proxy reverso ou balanceador de carga. Servidores intermediários ajudam a melhorar a escalabilidade e podem ser usados para lidar com a segurança, de modo que os servidores sejam responsáveis apenas pela lógica de negócios.
Clientes e intermediários HTTP podem armazenar em cache as respostas do servidor para reduzir a carga no servidor e aumentar a velocidade de entrega de dados aos usuários finais. O servidor deve indicar se uma resposta pode ser armazenada em cache ou não, com o último garantindo que as respostas às solicitações subsequentes do usuário final estejam corretas e atualizadas (não potencialmente “obsoletas”). Como os clientes acessam um recurso por sua URL, que é um identificador exclusivo, o cliente pode determinar o que armazenar em cache no nível do recurso.
Código sob demanda significa que o servidor pode enviar código executável para estender ou personalizar temporariamente a funcionalidade do cliente, eliminando a necessidade de o cliente implementar a funcionalidade por conta própria. A restrição de código sob demanda é opcional.
A representação ou abstração de dados mais importante em REST é um recurso. Um recurso REST pode ser qualquer tipo de informação abstrata – de um documento digital a um objeto não digital. O estado do recurso em qualquer momento é chamado de representação do recurso .
Uma representação de recurso tem três partes:
Uma API REST consiste em um conjunto de recursos interligados (ou seu modelo de recursos ) que são acessíveis em URIs exclusivos. Um cliente pode obter funcionalidade flexível vinculando-se a recursos e URIs relacionados dentro da resposta. Em geral, uma solicitação para 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 solicitação HTTP são usados para atuar em recursos da maneira indicada:
Nos estilos arquitetônicos REST, os identificadores de recursos designam exclusivamente cada recurso envolvido nas interações cliente-servidor.
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 conhecidos como hipertexto , embora de forma um pouco diferente). Hipermídia é qualquer conteúdo com links para outras mídias. A hipermídia como mecanismo de estado da aplicação (HATEOAS) é o que torna a arquitetura REST única.
Observação: De acordo com Roy Fielding, para uma API ser considerada uma API REST, ela deve usar hipermídia . No entanto, muitos designers de API hoje costumam chamar suas APIs de “REST[ful]” como um termo da moda, mesmo que não usem hipermídia/hipertexto.
As representações de recursos visam ser autodescritivas, o que significa que a API se faz entender dentro de seu próprio contexto. Com representações autodescritivas, o cliente não precisa saber a qual categoria um recurso pertence e, em vez disso, age com base no tipo de mídia associado ao recurso.
Hoje, a maioria das empresas usa APIs desenvolvidas internamente e de terceiros para comunicação entre aplicativos que fornecem funcionalidades básicas, inovadoras e críticas. A maioria dessas APIs são APIs REST, porque os padrões de comunicação específicos exigidos pelo REST permitem uma troca de informações 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 solicitações antes que uma resposta seja enviada. Para verificar as identidades dos usuários, as APIs REST empregam autenticação HTTP (tanto Basic quanto Bearer Token ), chaves de API e OAuth para acesso de login.
Outros benefícios das APIs REST incluem:
Embora REST continue sendo a arquitetura mais popular para conectar aplicativos cliente e servidor, GraphQL (desenvolvido pelo Facebook em 2012 e disponibilizado em código aberto em 2015) foi projetado como uma alternativa ao REST. As APIs GraphQL são mais eficientes que as APIs REST porque todos os dados necessários são solicitados em uma única solicitação e em um formato padronizado, mas ainda há algumas áreas em que o REST se destaca. GraphQL requer uma curva de aprendizado íngreme e é muito menos armazenável em cache do que REST. Além disso, os aplicativos geralmente são orientados por recursos e não exigem uma linguagem de consulta como GraphQL. Dito isso, cada modelo tem seus prós e contras e as organizações podem escolher usar ambos.
A flexibilidade das APIs REST é certamente uma vantagem. Mas muita flexibilidade também pode levar à criação de uma API potencialmente lenta ou quebrada, e é por isso que muitos desenvolvedores optam por publicar, gerenciar e gerar documentação de APIs usando a Especificação OpenAPI .
O API Connectivity Manager , parte do F5 NGINX Management Suite , oferece suporte à especificação OpenAPI para APIs REST. O API Connectivity Manager foi projetado com a experiência do desenvolvedor de API em seu núcleo. É uma solução de gerenciamento de API leve e nativa na nuvem com integração perfeita para publicação de APIs no portal do desenvolvedor e no gateway de API.
Inicie uma avaliação gratuita de 30 dias do NGINX Management Suite , que inclui o API Connectivity Manager e o Instance Manager .