O que são APIs?

Dá pra dizer que API é um termo que já faz parte do dia a dia de qualquer Product Manager. Acho que uma das frases que mais uso é "mas não dá pra gente criar uma API e a gente bater num endpoint pra pegar essa info?". Ok, não tá no top 10 de que mais uso, mas ela surge algumas vezes por trimestre.

Mas o que são APIs, de fato?

Nessa pequena série vou tentar trazer alguns conceitos mais básicos que aprendi ao longo da minha carreira e com meus hobbies para ajudar novos PMs ou só pra deixar registrado para futuras consultas. Hoje vamos falar de APIs, focando no REST.

Arquitetura e APIs.

Quase todos os produtos digitais funcionam com três blocos principais: o client/interface, um servidor e uma base de dados.

O client/interface é onde o usuário, normalmente, interage: um site, um aplicativo no celular, um .exe no computador, etc.
O servidor é um computador que está ligado na internet que vai processar o que você pedir pra ele. (um dia faço um post desses sobre servidores/internet)
A base de dados é onde vão ficar armazenadas quaisquer informações que se deseja armazenar. Pense nelas como um belíssimo .csv ou uma planilha do excel: com colunas e valores.

Quando você pesquisa algo no MercadoLivre, o site que está renderizado no seu computador manda uma requisição pro servidor. Essa requisição/comunicação é feita via uma interface de programação de aplicação, uma API (application programming interface).

Como funciona uma API?

APIs estão em todo lugar na internet. Existem 3 tipos delas:

Públicas: APIs que podem ser usadas e acessadas por qualquer pessoa. Significa que qualquer desenvolvedor pode usar e construir coisas com ela.
Privadas: Usadas de maneira interna nas empresas, digamos que uma empresa tem uma aplicação que se comunica com outra aplicação interna com dados sensíveis, aqui uma API privada faz essa comunicação acontecer de maneira segura e não é acessível a pessoas externas.
Parceiras: Um meio termo entre as duas anteriores, normalmente são APIs de empresas que permitem que sejam desenvolvidas soluções mas que exigem um nível de parceria. O Twitter, por exemplo, tinha uma API que permitia o uso de outros aplicativos para enviar e ler tweets e era exigido que o desenvolvedor fosse parceiro e fizesse pagamentos proporcionais ao uso da API. Infelizmente o twitter matou isso uns meses atrás.

Agora como, de fato, funciona uma API?

Separando em etapas, é mais ou menos assim:

Quando você entra no MercadoLivre e digita "iPhone" na busca, o site manda uma requisição para a api, digamos api.mercadolivre.com, solicitando todos os produtos com nome iPhone.
O servidor processa a requisição e faz uma "query" na base de dados.
A base de dados retorna pro servidor a listagem de todos os produtos que são iPhone 15.
O servidor pega essa listagem e envia pro site/client.

E ai você finalmente verá uma lista de iPhones na sua tela.

O servidor não é a API ou vice-versa. A API é uma aplicação que roda no servidor. Ela é um conjunto de ações disponíveis pro client. No caso a ação de listar é uma das funcionalidades da API que está rodando no servidor.

Essas ações são o que chamamos de endpoints. Imagine que além de precisar listar produtos a API do MercadoLivre também precise informar o valor do frete, a reputação do vendedor, etc. Cada uma dessas ações é um endpoint.

Exemplos:

Digamos que você listou os iPhones usando o endpoint de listagem.
- É enviado a requisição de iPhone para api.mercadolivre.com/listing que vai te retornar a listagem de produtos como termo.
Agora você quer calcular o frete.
- É enviado uma requisição com o seu CEP para a api.mercadolivre.com/frete que te retorna o R$45 de frete.

Por aí, vai. Estamos então falando que a API fica em api.mercadolivre.com e o endpoint é o /listing.

POST e GET

Existem vários tipos de requisições que podem ser feitas pra uma API, as duas principais e mais comuns são POST e GET.

As requisições de GET são requisições mais simplificadas e menos seguras, pois como verá abaixo a requisição fica toda visível na URL. No exemplo anterior, se você entrar no MercadoLivre e quiser a listagem de iPhones. É uma requisição GET para o endpoint /linsting na API que vai te entregar a listagem. Requisições GET enviam as informações na url como parâmetros.

https://api.mercadolivre.com/listing?product=iphone

As requisições POST são requisições que submetem dados para o servidor no corpo da requisição e não na url. Portanto, quando você envia um POST para um endpoint você envia o que chamamos de body que pode ser um conjunto de parâmetros e valores. Costumeiramente POST é usado em requisições que exigem mais informações pois o GET tem um limite de 2.048 caracteres. Abaixo um exemplo de POST com um carrinho montado no MercadoLivre.

https://api.mercadolivre.com/cart

Body:

{ "product": "Apple iPhone 15", "coupon": "desconto10", "cep": "50050450", "paymentmethod": "Pix" }

Tipos de APIs

Existem diferentes tipos de especificações de APIs. Não irei entrar no detalhe porque é um nível mais profundo mas vale destacar as três a seguir:

REST: A mais comum, usa protocolo http/web para receber as requisições. Ela que usa as requisições GET e POST acima e foi a que focamos aqui nesse texto.
SOAP: Uma especificação mais antiga que usa somente XML como formato.
GraphQL: Especificação bem recente criada no Facebook/META, tem um foco em eficiência de trazer somente os dados requisitados e nada mais, além de permitir extrair dados de várias fontes usando somente uma requisição. Ela também pode ter mutações para funcionar como uma POST criando recursos.

Caso deseje se aprofundar em qualquer um dos temas aqui deixei no fim do post alguns links que usei no passado para estudar sobre.

Conclusão

APIs são aplicações que rodam em servidores e executam ações através de endpoints, podem elas serem públicas ou privadas. APIs estão em todos os lugares na internet e em produtos. Fazem parte da realidade de qualquer Product Manager e é importante ter os conhecimentos básicos sobre porque vai facilitar bastante a comunicação com os desenvolvedores e quem sabe a achar possíveis soluções para determinados problemas.

disclaimer: Este texto é uma simplificação destinada a apresentar conceitos iniciais de tecnologia para um público não técnico, como Product Managers ou curiosos. O autor não é desenvolvedor, e as informações fornecidas são generalizações para facilitar a compreensão inicial. Recomenda-se consultar fontes adicionais para obter uma compreensão mais completa e precisa.

Links úteis: