O que é uma API (Interface de Programação de Aplicações)?

Uma API é um conjunto de regras que permite a uma aplicação solicitar dados e funcionalidades de outra sem conhecer o código interno dela. A famosa analogia do restaurante — você pede pelo cardápio, a cozinha fica invisível — merece sua única frase e nada mais, porque a coisa real é mais instrutiva que a metáfora: uma API é um contrato, e contratos são precisos.

Principais pontos

Anatomia de uma requisição e resposta de API HTTP

Nenhum explicador bem ranqueado mostra uma, então aqui está uma chamada de API inteira — requisição e resposta, nada escondido:

POST /classes/Todo HTTP/1.1              ← método + endpoint
Host: api.example-backend.com
X-Api-Key: app-7f2c…                     ← identifica o app que chama
Authorization: Bearer eyJhbGci…          ← autentica o usuário
Content-Type: application/json

{ "title": "Ship the release", "done": false }

HTTP/1.1 201 Created                     ← status: funcionou, recurso criado
Location: /classes/Todo/xKd91m
Content-Type: application/json

{ "objectId": "xKd91m", "createdAt": "2026-07-24T10:30:00Z" }

A mesma chamada por um SDK — que não é nada além deste HTTP, embrulhado no idioma da sua linguagem:

// JavaScript / Node.js — Back4app JS SDK
// One API call: create a record via the auto-generated REST API
const todo = new Parse.Object('Todo');
todo.set('title', 'Ship the release');
todo.set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
console.log('Created with id', todo.id);

// Flutter / Dart — Back4app Flutter SDK
// One API call: create a record via the auto-generated REST API
final todo = ParseObject('Todo')
  ..set('title', 'Ship the release')
  ..set('done', false);
await todo.save();
// Under the hood: POST /classes/Todo with a JSON body → 201 Created
print('Created with id ${todo.objectId}');

// iOS / Swift — Back4app Swift SDK
// One API call: create a record via the auto-generated REST API
var todo = Todo()
todo.title = "Ship the release"
todo.done = false
todo.save { result in
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if case .success(let saved) = result { print("Created with id \(saved.id ?? "")") }
}

// Android / Kotlin — Back4app Android SDK
// One API call: create a record via the auto-generated REST API
val todo = ParseObject("Todo")
todo.put("title", "Ship the release")
todo.put("done", false)
todo.saveInBackground { e ->
    // Under the hood: POST /classes/Todo with a JSON body → 201 Created
    if (e == null) println("Created with id ${todo.objectId}")
}

Como funciona uma chamada de API

Três propriedades desse ciclo explicam por que APIs sustentam a stack moderna. Abstração: quem chama precisa do contrato, nunca da implementação — o provedor pode reescrever tudo atrás da interface sem quebrar um único cliente. Fronteira: validação e permissões vivem na interface, e é por isso que clientes falam com APIs e nunca com o banco de dados diretamente — uma API não é um banco de dados; é o porteiro na frente de um. Composição: como toda capacidade é chamável, aplicações se montam a partir de serviços — auth aqui, pagamentos ali, mapas de um terceiro — e, cada vez mais, agentes de IA usam o mesmo substrato: tool calling é chamada de API com um modelo decidindo as requisições.

O contrato: o que uma API realmente promete

As páginas que chamam uma API de “contrato” raramente mostram um. Hoje o contrato é um documento legível por máquina — a OpenAPI Specification é o padrão para APIs HTTP — listando cada endpoint, parâmetro, schema e código de status. A partir desse único arquivo, o ferramental gera documentação de referência, bibliotecas de cliente, stubs de servidor, servidores de mock e testes de contrato.

O enquadramento de contrato tem dentes por causa do versionamento. Adicionar um campo de resposta não quebra ninguém; renomear ou remover um quebra todo consumidor em silêncio — por isso APIs maduras distinguem mudanças aditivas de mudanças que quebram, versionam sua superfície (/v1/, ou via headers) e publicam janelas de descontinuação. Uma API sem política de mudança é um contrato sem cláusulas: tecnicamente uma promessa, na prática uma surpresa.

Os tipos de API

Com formato de busca, porque “tipos de API” é uma pesquisa por si só: duas taxonomias, não uma.

Por público:

Por estilo: REST (recursos em URLs, métodos HTTP), GraphQL (consultas moldadas pelo cliente em um único endpoint), gRPC (binário, contract-first, serviço a serviço), SOAP (envelopes XML, padrões enterprise/legados) e APIs WebSocket (bidirecionais, persistentes) — comparados na tabela a seguir.

E um parágrafo que os explicadores da web pulam: nem toda API é uma API web. A biblioteca padrão de uma linguagem, as chamadas de sistema POSIX e as interfaces embutidas do navegador, como fetch e geolocalização, são todas APIs — contratos entre programas — que nunca cruzam uma rede. A variedade web apenas colocou o contrato atrás de uma URL.

REST vs. GraphQL vs. gRPC vs. SOAP vs. WebSocket

Casos de uso comuns

• Backends mobile e web — os dados de cada tela chegam por uma API; o frontend nunca toca o banco de dados.
• Integração com terceiros — pagamentos, identidade, mensageria, mapas: capacidades alugadas por contrato em vez de reconstruídas.
• Comunicação entre microsserviços — APIs internas como as costuras que deixam serviços fazerem deploy e escalarem de forma independente.
• Automação e scripts — qualquer coisa com API pode ser orquestrada: pipelines de CI, infraestrutura, fluxos de conteúdo.
• Agentes de IA e tool calling — modelos agem invocando APIs; um contrato bem documentado agora é consumido por máquinas duas vezes, por SDKs e por agentes.

Qual estilo de API você deveria escolher? Matriz de decisão

Limitações e trade-offs

• Um contrato também obriga o provedor. Cada campo publicado vira algo de que alguém depende; a evolução acontece por disciplina de versionamento, não por edições silenciosas.
• APIs de rede herdam a rede. Latência, falha parcial e retries fazem parte da semântica de toda chamada remota — chamadas de função locais nunca precisaram de política de timeout.
• Abstração esconde custo. Uma chamada de aparência inocente pode se espalhar em trabalho caro; consumidores veem o cardápio, não a conta da cozinha — é para isso que existem rate limiting e cotas.
• A superfície de segurança escala com a área exposta. Cada endpoint é uma porta; chaves identificam mas não autorizam, então auth de verdade (tokens no estilo OAuth 2.0, permissões por usuário) e validação de entrada são o mínimo aceitável.
• Formatos fixos servem mal a alguns consumidores. Os trade-offs de overfetching/underfetching do design por endpoint são um tópico próprio — veja o verbete irmão.

APIs no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O movimento definidor é que a API é gerada, não construída: defina um modelo de dados e a plataforma o expõe imediatamente como endpoints REST e um schema GraphQL — a chamada dissecada acima é o formato real do fio no Back4app — com chaves, tokens de usuário e permissões por classe fazendo valer o contrato na fronteira. Os SDKs consomem essa API de forma idiomática em todas as principais plataformas, e operações customizadas viram funções de Cloud Code: endpoints novos em um arquivo, a mesma disciplina de contrato, nenhum servidor para rodar.