API é a abreviação de Application Programming Interface (Interface de Programação de Aplicativos) e é um trecho de código que especifica como diferentes componentes de software devem interagir e se comunicar programaticamente. Muitos não sabem que, na maioria das interfaces de usuário modernas, dezenas de solicitações estão sendo enviadas aos servidores de API para obter dados. Em seguida, o cliente processa os dados retornados pelo servidor de API para obter algum resultado na interface do usuário.
Por exemplo, se você já pesquisou em um site agregador as melhores ofertas de voos ou reservas de hotéis, foi feita uma “solicitação” de dados com base em seus critérios de pesquisa (após clicar no botão enviar) para uma API especializada em voos ou reservas. Depois que o site agregador recupera os dados usando a API, os resultados da pesquisa são exibidos para você.
O site agregador e seus bancos de dados associados não armazenam os dados que aparecem nos resultados da pesquisa. Em vez disso, o site enviou uma solicitação de dados correspondentes aos seus critérios de pesquisa a um serviço da Web externo (ou seja, API). A API retornou os dados solicitados ao site, e o site analisou os dados e apresentou os resultados da pesquisa.
O que é uma API REST?
Há muitos tipos de APIs. Para descrever todas elas de forma suficiente aqui, seriam necessárias muitas publicações no blog. Para nossos objetivos futuros, limitaremos o escopo da discussão sobre APIs apenas às APIs REST.
REST significa transferência de estado representacional e é um tipo específico de estilo arquitetônico ao qual as APIs consideradas “RESTful” estão restritas e “em conformidade”.
As APIs REST são um tipo muito comum e importante de API que usa o protocolo HTTP para a transmissão de dados. Como esse protocolo HTTP é usado, uma API REST é considerada um “serviço da Web” que lida com a interação entre aplicativos clientes e servidores de API. Usando esse protocolo, um cliente envia uma solicitação HTTP de dados para um servidor de API e, em seguida, o servidor envia uma resposta HTTP com dados codificados de volta para o cliente.
O protocolo HTTP usado pelas APIs REST permite que plataformas e sistemas escritos em diferentes linguagens de programação interajam entre si. Por exemplo, um aplicativo cliente escrito em C# pode interagir com um servidor de API escrito em Java. Essa interoperabilidade entre sistemas torna os serviços da Web muito populares no desenvolvimento de software moderno e, em particular, as APIs REST.
Também leia: O que é API aberta? Vantagens, Desvantagens & Exemplos
Casos de Uso API REST
A separação das preocupações do cliente e do servidor no REST o torna atraente para muitos tipos de projetos, seja desenvolvimento móvel, desenvolvimento da Web etc.
Aqui estão os casos de uso comuns:
- Aplicativos em nuvem – As vantagens de statelessness – sem estado(discutidas mais tarde) dos REST são adequadas aos aplicativos em nuvem.
- Cloud Computing – REST suporta a computação de nuvem no controle de como URLs são decodificadas durante a comunicação cliente-servidor.
- Microserviços – APIs REST conectam microserviços juntos em um aplicativo.
Anatomia da solicitação da API REST
As APIs definem as regras de como aplicativos do cliente/backends e servidores da API podem se comunicar programaticamente. A API determina como o cliente precisa enviar requisições, e que tipo de informação é retornada pela API para o cliente.
Os componentes básicos das solicitações de API REST são discutidos abaixo.
Recursos
Os diferentes tipos de informação que o cliente pode solicitar da API são chamados de “recursos”. Pense em um recurso como um tipo de objeto de dados retornado pela API.
Por exemplo, a famosa API Swagger Petstore consiste de vários recursos, nome: Pet, Store e Usuário.
Todas relacionadas ao tema central da pet store, mas cada uma representa os diferentes objetos de dados que você pode criar, manipular ou excluir.
Ao ler a documentação da API, você perceberá que os pontos de extremidade são agrupados sob o recurso relacionado. Por exemplo, o recurso “pet” tem vários pontos de extremidade relacionados (discutidos em breve) para realizar ações em um recurso pet. Você pode criar, atualizar ou excluir Pets.
Para solidificar o conceito de recursos: Quando você cria um Pet, saiba que a API retorna um recurso Pet ou um “objeto” Pet que, de certa forma, representa um animal de estimação físico adicionado ao sistema da loja de animais.
Endpoints
Se você expandisse o recurso pet ou store, veria vários pontos de extremidade. Cada endpoint faz algo diferente.
Os pontos de extremidade estão no centro das solicitações de API e geralmente se destacam na documentação da API. Mais notavelmente, o método (ou ação, como POST) da solicitação e o caminho final (ex. /pet) do endpoint são destacados. A seguir, uma lista de endpoints do recurso pet.
Ao enviar uma solicitação a uma API, você envia uma solicitação HTTP usando o “caminho final” específico do ponto de extremidade. O caminho final vem depois do URL base da API. Por exemplo, o caminho base da Swagger Petstore é https://petstore.swagger.io/v2/, enquanto um caminho final para um ponto de extremidade de loja de animais se parece com /pet. O URL completo do recurso usado para enviar uma solicitação é https://petstore.swagger.io/v2/pet.
Um ponto de extremidade pode ter vários caminhos e métodos (discutidos em breve) que obtêm respostas diferentes de um recurso. A solicitação abaixo envia uma solicitação usando o ponto de extremidade /pet com o método POST. POST indica que você deseja criar algo, nesse caso, um animal de estimação.
A solicitação abaixo envia uma solicitação usando o mesmo ponto de extremidade /pet, só que desta vez você usa o método GET para recuperar detalhes de um animal de estimação em vez de criar um. Observe que você precisa anexar o petId do animal de estimação à sua solicitação (parâmetros discutidos posteriormente).
Métodos
Como brevemente discutido, métodos HTTP são enviados com solicitações de API para indicar as ações que você gostaria de tomar em direção a um recurso. Existem muitos métodos de API, portanto vou listar apenas alguns importantes métodos:
- Solicitação POST – cria um recurso.
- GET request – recupera/buscar informações sobre um recurso.
- Solicitação PUT – atualiza ou cria um recurso.
- Solicitação DELETE – exclui um recurso.
Os métodos HTTP correspondem a operações CRUD. Por exemplo, os métodos HTTP POST, GET, PUT, e DELETE correspondem à criação, leitura, atualização e exclusão das operações CRUD.
Parâmetros
Pense nos parâmetros como opções ou filtros passados com um ponto de extremidade que afetam quais informações são retornadas na resposta. Existem diferentes tipos de parâmetros, tais como:
- Parâmetros de cabeçalho – Incluídos no cabeçalho de solicitação de uma solicitação de API e geralmente estão relacionados à autorização. Por exemplo, muitas vezes um parâmetro de token de acesso é incluído no cabeçalho da solicitação que autoriza as solicitações do cliente para a API.
- Parâmetros de caminho – Incluídos no URL do recurso de uma solicitação de API e são indicados por chaves no final do caminho final de um ponto de extremidade. Por exemplo, GET /pet/{petId}.
- Parâmetros de cadeia de consulta – Incluídos no URL do recurso de uma solicitação de API e aparecem depois de uma aspa (?).
Observe que endpoints podem ou não usar todos esses tipos de parâmetros. No entanto, parâmetros de cabeçalho geralmente estão incluídos para autorização de solicitações.
Corpo da solicitação
Os corpos de solicitação são essencialmente objetos JSON passados no corpo de uma solicitação de API e são frequentemente usados com os métodos POST ou PUT. Embora não sejam classificados como tal, eles são como parâmetros que assumem a forma de um objeto JSON em vez de um par de valores-chave como um parâmetro norma
Princípios fundamentais do REST
Os princípios fundamentais do REST são o que o torna tão atraente no desenvolvimento de software.
Cliente e Servidor
As APIs REST têm uma arquitetura projetada para separar o cliente do servidor, para que ambos possam evoluir de forma independente. O cliente não se preocupa com o armazenamento de dados do servidor, e o servidor não se preocupa com a interface do usuário. Essa separação de preocupações torna as interfaces de usuário muito portáteis e os elementos do servidor mais dimensionáveis.
Assistência
A restrição de sem estado do REST garante que os dados de estado sejam armazenados apenas no aplicativo cliente e não no servidor. Cada pedido feito pelo cliente é independente de quaisquer solicitações anteriores e inclui todas as informações necessárias. Uma vez que o servidor não armazena nenhuma informação relacionada à sessão, o aplicativo do cliente gerencia seus dados de sessão.
Armazenável em cache
Quando um cliente envia uma solicitação a uma API REST, a API deve indicar que a resposta pode ou não ser armazenada em cache. Além disso, ela deve indicar por quanto tempo o cliente pode armazenar as respostas em cache. O armazenamento em cache pode melhorar a disponibilidade e o desempenho reduzindo o número de solicitações de API, pois o cliente pode aproveitar os dados armazenados em cache por um determinado período de tempo.
Interface Uniforme
APIs RESTful são restringidas de formas que fazem uma interface uniforme para clientes. Por exemplo, APIs RESTful devem:
- Identificar seus recursos.
- Usar o protocolo HTTP para descrever suas operações (por exemplo, POST, GET, PUT, DEL).
- Usar mensagens auto-descritivas que permitem interpretação pelo cliente sem conhecimento específico do aplicativo.
- Exigir que as aplicações do cliente usem hiperlinks para interações com os recursos da API.
Sistema em camadas
REST permite uma arquitetura de sistema em que cada camada desempenha um certo papel no sistema e só interage com outras camadas designadas. Por exemplo, você pode ter um servidor de API, um servidor de armazenamento de dados e um servidor para autenticar solicitações de clientes usando uma arquitetura em camadas.
Também pode haver servidores intermediários entre o cliente e o servidor que lidam com segurança, balanceadores de carga e proxies que podem melhorar a disponibilidade do sistema.
Benefícios do REST
Escalabilidade
A separação do cliente dos componentes do servidor aumenta a portabilidade e a simplificação dos componentes do servidor. A arquitetura multi-camadas do REST também restringe a interação de camadas. Estes fatores contribuem para a escalabilidade do REST.
Portabilidade / Independência
Como a interface do usuário é separada do servidor, ele pode ser portado para muitas plataformas diferentes. APIs REST em si também são adaptáveis entre plataformas, o que permite testes fáceis durante o desenvolvimento.
Flexibilidade
A separação cliente-servidor também facilita a migração de dados entre os servidores e a implantação de novas mudanças rapidamente.
Usa Menos Banda
APIs RESTful são vantajosas sobre APIs SOAP em termos de largura de banda. As APIs REST enviam e recebem pagamentos JSON comumente como oposição ao SOAP que usa XML. payloads XML são maiores do que JSON, fazendo APIs SOAP requerem mais largura de banda do que APIs REST.
Integração Fácil
APIs REST são geralmente mais fáceis para os desenvolvedores integrarem em seus aplicativos porque eles podem se concentrar mais na interface do usuário, funcionalidade e regras de negócio em vez de componentes de servidor e gerenciamento de dados manipulados pelo Servidor de API.
Desafios no uso da REST
Embora os prós do uso do REST superarem os contras, as equipes de desenvolvimento ainda devem estar cientes dos possíveis problemas desse estilo de arquitetura.
Confiabilidade do Endpoint
Embora seja a melhor prática para URLs de endpoints de API serem consistentes à medida que uma API evolui, a uniformidade dos URL pode se tornar um problema para sistemas maiores, à medida que o número de caminhos e métodos de extremidade possíveis aumenta.
Controle de versão API
À medida que novas versões das APIs são lançadas, o controle de versão inevitavelmente se torna uma emissão que as equipes de desenvolvimento têm dificuldade em gerenciar. Para proteger a compatibilidade, os endpoints mais antigos requerem que o apoio permaneça válido até que sejam gradualmente eliminados. Isto implica custos de tempo e recursos.
Tempo de Resposta Aumentado
Um exemplo de dois fatores que podem causar lentidão no tempo de resposta é o tamanho de um servidor e o número de servidores envolvidos no processamento de uma chamada de API e na recuperação de dados. Com bases de dados maiores vem mais dados que têm de ser ordenados e tratados, especialmente se existirem numerosas bases de dados.
Respostas de Dados Grandes
Às vezes é inevitável quando a resposta de um servidor para uma solicitação de API fornece desnecessariamente todos os dados possíveis quando apenas um subconjunto é necessário. O aplicativo cliente tem que ser robusto o suficiente para analisar as informações e extrair o que precisa. Uma solicitação GET é uma ocorrência comum que pode acionar a recuperação de muitos dados.
Segurança
Enquanto a arquitetura em camadas do REST tem benefícios de segurança, isso não significa que os aplicativos não precisam ser criptografados. Sem criptografia, os aplicativos podem expor dados confidenciais.
Principais exemplos de API REST
Plaid
O mercado para o SaaS (Software como um serviço) está provocando um grande crescimento para as APIs REST na arena FinTech. Uma das principais empresas é Plaid, que se encontra entre um número selecionado de empresas que promovem a “democratização dos dados” nos serviços financeiros.
A “democratização” tem a ver com disponibilizar dados para todas as partes (desenvolvedores, partes do mundo empresarial, consumidores), independentemente das suas competências técnicas. Este modelo permite que você aproveite o potencial bruto de dados para criar experiências que se adequam às necessidades do usuário final.
Plaid adota uma abordagem altamente “caso de uso” orientada para a forma como comercializa o potencial dos seus serviços. A comunicação e orientação claras de como alavancar seus serviços é um diferenciador.
Por exemplo, há toda uma série de casos de utilização que levam alguém a utilizar os serviços de Plaid, seja para aplicativos em finanças pessoais, pagamentos de consumidores, empréstimos, banco ou gestão de riqueza. Cada caso de uso é explicado em detalhes na sua documentação. Plaid também tem conexões com milhares de instituições financeiras que os desenvolvedores podem utilizar em seus aplicativos.
No que diz respeito às mídias sociais, o alcance do Twitter é enorme, com uma média de 206 milhões de usuários ativos. Os desenvolvedores devem estar cientes dos benefícios da API do Twitter para integrar as funcionalidades do Twitter, promovendo simultaneamente as suas aplicações através da plataforma.
Por exemplo, os desenvolvedores podem utilizar o processo de identificação do Twitter para reduzir ou eliminar o processo de registro. A API permite que você exiba tweets para os seus usuários com base em certos critérios, como localização ou hashtags em tendência. O alcance do Twitter também permite que você comercialize seus aplicativos de forma efetiva usando os dados dele.
Enquanto outras APIs de empresas notáveis de mídia social estão disponíveis, são as capacidades e alcance da API do Twitter que fazem com que ela se destaque.
Serviços AWS AI
APIs REST para inteligência artificial, ciência de dados e aplicativos de aprendizado de máquina estão crescendo constantemente. Entre as empresas mais altas que oferecem estes serviços encontram-se os serviços AWS AI (por exemplo, Amazon) que permitem aos desenvolvedores incorporar a funcionalidade de IA nos seus aplicativos para fazer uma interação mais adaptável e inteligente. A IA também pode ajudar a proteger o intercâmbio de dados entre sistemas, detectando potenciais vulnerabilidades de segurança.
Embora existam muitos APIs de IA Os serviços da Amazon oferecem o maior leque de funcionalidades entre os seus tipos e têm o benefício acrescido da fácil integração do seu lado.
Em resumo
As APIs se tornaram a cola que une sistemas separados, permitindo que eles troquem dados usando um modelo arquitetônico comum (principalmente REST), o que aumenta a escalabilidade, a flexibilidade e a independência à medida que clientes e servidores evoluem independentemente uns dos outros.
Leia também: 6 melhores ferramentas de documentação de API
Tanto as novas startups quanto as empresas de tecnologia consolidadas estão expandindo suas ofertas existentes e lançando novos produtos SaaS à medida que a “democratização dos dados” se torna importante para as empresas que desejam permanecer na vanguarda.
A conversa sobre o valor das APIs não está mais no domínio exclusivo dos “programadores”. As partes interessadas de todas as áreas de negócios podem se beneficiar da compreensão das APIs e de como elas podem ser usadas para resolver desafios comerciais.
Agende uma demonstração com um de nossos especialistas para aprofundar o processo no Document360
Reserve uma demonstração