Olá, estudante! Na lição de hoje, você aprofundará seu conhecimento em um assunto que já foi mencionado em lições anteriores, que é a API (Application Programming Interface, ou, em português, Interface de Programação de Aplicações). Em nossa última lição, foi abordado o tema na utilização de serviços e APIs na Internet em que a sua atuação é mais como cliente dessas APIs. Agora, você entenderá como construir e como funcionam as APIs do ponto de vista de servidor, ou seja, para que outras pessoas, no caso de API externa, ou outros projetos seus consumam essa API e/ou serviço.

Você conhecerá a API que o React Native disponibiliza para os desenvolvedores e o conceito de APIs Rest. Segundo MDN Wed Docs (2023), REST é um recurso, por exemplo, um documento, que é transferido com seu estado, padronização de operações e formatos bem definidos ou com serviços que se autodenominam RESTful, quando modificam diretamente o tipo de documento, ao invés de desencadear ações em algum lugar. Sendo assim, o objetivo desta lição é apresentar informações a respeito de APIs e como utilizar os eventos da API do React Native, além de falarmos sobre os conceitos de API Rest e sobre como publicar essas APIs uma vez estando disponíveis.

Uma situação que foi um grande problema e gerou muito custo para as empresas foi o fato de que um sistema era construído com toda a regra de interfaces do usuário em somente um projeto. O problema disso era que, quando era necessário expandir os domínios desse sistema — em relação ao software instalado em cada um dos computadores que eram utilizados —, a simples necessidade de se replicar a base de dados e/ou sistema na forma web já era um grande empecilho, pois, de fato, era necessária uma replicação de tudo, regra de negócio, interface, banco de dados etc.

Com o surgimento das APIs, as equipes começaram a criar seus projetos ainda de forma unificada, porém consumindo suas próprias APIs, que foi o conceito amplamente divulgado pela linguagem JAVA, o chamado MVC (Model, View e Controller), em que era possível, por meio de uma API, criar toda a regra de negócio, que se encaixaria no M (modelo) de MVC, e criava-se, então, projeto com o controlador (controller) e com a view (visão) necessária para aquele momento.

Com isso, foi se estabelecendo o padrão utilizado hoje, em que se cria uma API que se conecta com o banco de dados e com o seu projeto desktop, e, se, por exemplo, surgir a necessidade de site/sistema web, basta que você crie o projeto web e consuma da mesma API, ou, então, pensando na questão mobile, crie seu aplicativo que se servirá, também, da mesma origem dos dados. Dessa forma, você garante um padrão dos dados e de regras independentemente do ambiente, incluindo, como já citado anteriormente, o desenvolvimento de aplicativos para dispositivos móveis.

O case fictício apresentado hoje será sobre a empresa Integration Software S.A., que desenvolveu um sistema para gerenciamento de uma rede de supermercados brasileira. O projeto contempla os seguintes requisitos: software desktop instalado nas máquinas do caixa, sistema web para gestão do estoque do supermercado — que pode ser acessado tanto pelo administrativo de uma unidade quando pelo diretor geral da rede, por isso, a necessidade de ser web — e um aplicativo para dispositivos móveis de pedidos diretamente para o cliente.

A equipe designada para esse projeto, logo de cara, percebe que, se fossem criados três softwares em três plataformas diferentes — e, com certeza, com mais de uma linguagem de programação e conjunto de tecnologias, incluindo banco de dados —, o trabalho seria bem maior e, também, os softwares teriam uma manutenção muito complicada, tendo em vista que toda alteração que ocorresse em algum deles deveria ser replicada nos outros dois. Mas, então, qual a solução para isso?

Pensando em uma solução, a equipe optou pela construção de toda regra de negócio e interação com banco de dados. Das três aplicações, os dados seriam manipulados por meio de uma API RESTful e entregues no formato JSON (JavaScript Notation Objects) e, independentemente da tecnologia dos três softwares, a criação e a recuperação dos dados de banco de dados seriam as mesmas.

A equipe demandou grande esforço na construção dessa API e, na sequência, começou a construção do software web de gestão de estoque e, em paralelo, implementou o aplicativo para dispositivos móveis e o sistema do caixa. Assim, pode-se chamar um case de sucesso de utilização de APIs no desenvolvimento de softwares e aplicativos profissionais com o que há de mais atualizado em termos de técnicas e tecnologia interoperabilizante.

Antes de iniciar os conceitos acerca de APIs em geral, abordarei, primeiramente, alguns aspectos, especificamente, o gerenciamento de Eventos, por meio de uma API do React Native para, na sequência, conceituar as APIs de maneira geral e especificar tais conceitos em uma API REST e, como consequência, uma API RESTful e finalizar com a abordagem de publicação dessas APIs.

Eventos 

Dentro dos aspectos de regra de negócio de uma API, existe um tipo de componente/funcionalidade chamado Eventos (Events). Mas o que seria um evento na prática? 

Dentro da API do framework React Native, por exemplo, temos um componente chamado AppState, que, segundo React Native (2023), é um componente que pode informar se o aplicativo está em primeiro ou segundo plano e notificá-lo quando o estado muda. Sendo assim, sempre que isso ocorre, o estado da aplicação muda, ou seja, isso significa que, na prática, o aplicativo passou do segundo plano para primeiro, ou, então, do primeiro plano para segundo. O que chamamos de Evento é disparado, notificando toda a aplicação. 

APIs 

Agora chegou o momento de formalizarmos as devidas apresentações sobre o tema. Mas, verdadeiramente, o que é uma API? Segundo AWS ([2023]), APIs são mecanismos que permitem que dois componentes de software se comuniquem usando um conjunto de definições e protocolos.  

As APIs, por natureza, possuem a arquitetura no formato de cliente e servidor. Uma aplicação consumirá dados e informações de outra API, nesse caso, a aplicação que consome será o cliente e a aplicação que provê os dados e as informações servirá o cliente, ou seja, o servidor. Dentro desse formato, existem formas e/ou protocolos que uma API pode estabelecer essa comunicação. Veremos sobre elas a seguir.

SOAP 

São APIs que utilizam do SOAP — chamadas protocolo de acesso a objetos simples, em português —, quando as mensagens são trocadas entre cliente e servidor por meio de arquivos do tipo XML. É um formato um tanto quanto burocrático, muito utilizado no passado, mas, ainda, existe em sistemas legados.

RPC 

Nas Remote Procedure Calls — chamada procedimento remoto, em português —, o cliente se comunica com o servidor por meio de uma função ou procedimento em que o servidor retorna a saída dessa chamada.

WebSocket 

A WebSocket é um conceito mais moderno, usa objetos JSON para transmitir dados. Ela oferece suporte à comunicação bidirecional entre aplicativos cliente e servidor, ou seja, o servidor, também, pode enviar chamadas ao cliente com o objetivo de coletar informações.

APIs REST 

São as APIs mais utilizadas hoje no mercado por conta de sua flexibilidade, entre outros fatores. O cliente envia solicitações ao servidor, como dados, e o servidor usa essa entrada do cliente para iniciar funções internas que o cliente não sabe como são processadas e retorna os dados de saída ao cliente. 

Os “verbos” mais utilizados para integração com aplicativos para dispositivos móveis são os seguintes:

Outra característica de API REST são os “códigos de resposta HTTP” que ajudam na hora de entender se a sua requisição funcionou ou não. Os mais usados são os seguintes:

Ainda sobre os códigos de resposta HTTP, segundo MDN Web Docs (2022b), eles indicam se uma requisição HTTP foi, corretamente, concluída. As respostas são agrupadas em cinco classes:

Gosto muito de ressaltar a importância das duas últimas classes de respostas que dizem respeito a erros. Se você estiver consumindo uma API e, em determinado ponto, ela fica retornando algum erro na faixa de 400, você, como cliente, está fazendo algo errado e, se estiver retornando algum erro na faixa de 500, o servidor está com algum tipo de problema.

API RESTful 

Se você analisou e já entendeu que REST é um estilo de arquitetura, ou seja, uma série de restrições que devem ser seguidas no processo de criação de uma API e descritas por Roy Fielding em sua tese de PhD, você já entendeu 80% do conceito RESTful, pois, se a sua API está de acordo com todas as restrições definidas por Roy, sua API, então, é RESTful.

Restrições para uma API RESTful:

Publicação 

A questão de publicação de uma API pode ser um tanto quanto simples do ponto de vista de disponibilizá-la internamente para sua empresa, para seu projeto ou, até mesmo, para toda web. Você pode publicá-la de duas maneiras:

Com o conhecimento obtido nesta lição, acredito que fica fácil entender que API é vida! Brincadeiras à parte, na maioria das vezes, você trabalhará com uma API, seja consumindo uma em seu projeto, seja criando uma interna — mas não exclusiva — para seu atual projeto, e pode ser que você, ainda, não precise trabalhar com uma API (raríssimos casos).

Acredito, fortemente, que, se o projeto for alguma versão de apresentação, ou como se chama esse tipo de projeto, MVP (Mínimo Produto Viável, em português), ou seja, uma versão do projeto apenas para provar que seu projeto é válido e capaz de resolver o problema no qual ele se propões e, também, é capaz de captar investimentos para todo o desenvolvimento, você pode ter a opção de construir seu projeto sem necessidade de criar uma API separadamente. Mas, em todas as outras situações, principalmente no que é exposto nesta disciplina, criar uma API para tratar da regra de negócio, principalmente uma API RESTful, agilizará muito seu trabalho em possíveis atualizações e melhorias de seu aplicativo.

Portanto, para aplicar o conceito de APIs, basta que você separe a regra de negócio de seu aplicativo e comunicação com banco de dados em um projeto ou gateway separado e, a partir disso, fique tranquilo(a) para criar todo o design e comportamento da aplicação.