---
term: 'API (Interface de Programação de Aplicações)'
seoTitle: 'O que é API? Interface de Programação de Aplicações Explicada'
headline: 'O que é uma API (Interface de Programação de Aplicações)?'
slug: api
category: api-realtime
shortDefinition: '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.'
relatedTerms:
- rest-api
- graphql-vs-rest
- backend-sdk
- auto-generated-database-apis
- api-gateway-architecture
contrastsWith:
- backend-sdk
faq:
- question: 'O que significa a sigla API?'
answer: 'Application Programming Interface — em português, Interface de Programação de Aplicações. "Aplicação" é qualquer software com uma função distinta; "interface" é o contrato entre duas delas — o conjunto definido de solicitações que uma pode fazer e as respostas que a outra promete devolver. A parte de programação é o ponto: é uma interface para software, assim como uma UI é uma interface para humanos.'
- question: 'Para que serve uma API?'
answer: 'Para um programa usar dados e capacidades de outro sem ver como o trabalho acontece por dentro. Um programa expõe uma lista do que sabe fazer — buscar este dado, executar aquela ação — e outros invocam isso por meio de solicitações definidas. A ilustração clássica: um app de previsão do tempo não mede o céu; ele chama a API de um serviço de meteorologia.'
- question: 'Como funciona uma API?'
answer: 'Por requisição e resposta. O cliente envia uma requisição a um endpoint — uma URL que nomeia o recurso — com um método que declara a intenção, headers carregando metadados e credenciais e, às vezes, um corpo de dados. O servidor valida, faz o trabalho e retorna um código de status mais um corpo de resposta, geralmente JSON. Toda integração que você já usou se reduz a esse ciclo.'
- question: 'API é um banco de dados?'
answer: 'Não — é a camada de acesso na frente de um. A API define o que pode ser pedido e por quem; o banco de dados armazena os dados em si. Uma API frequentemente fica entre os clientes e um banco justamente para que os clientes nunca toquem o banco diretamente — validação, permissões e formatação acontecem na interface.'
- question: 'Qual a diferença entre API e SDK?'
answer: 'A API é o contrato; o SDK é um kit de ferramentas para consumi-lo. Um SDK embrulha chamadas de API em funções idiomáticas da linguagem e adiciona gestão de sessão, retries e tipos. Você chama uma API pela rede; você importa um SDK no seu código — e, por baixo, o SDK está fazendo chamadas de API.'
- question: 'Quais são os tipos de API?'
answer: 'Por público: públicas (abertas a qualquer desenvolvedor), de parceiros (compartilhadas com empresas contratadas), internas (privadas de uma organização) e compostas (agrupando várias chamadas). Por estilo: REST, GraphQL, gRPC, SOAP e APIs WebSocket. E além da web: APIs de bibliotecas e de sistemas operacionais — interfaces existiam muito antes de o HTTP transportá-las.'
- question: 'O que é um endpoint de API?'
answer: 'A URL específica onde uma API recebe requisições de um recurso — /users/42 é o endpoint do usuário 42. Endpoint mais método define uma operação: GET /users/42 o lê, DELETE /users/42 o remove. Endpoints são a superfície endereçável da interface inteira.'
- question: 'O que é uma chave de API (API key)?'
answer: 'Uma string gerada que o cliente envia com cada requisição para que o provedor identifique quem chama, meça o uso e aplique limites ou revogação. É mais identificação do que autorização — APIs de produção colocam autenticação de verdade por cima, como tokens emitidos via OAuth, para permissões por usuário.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'API — MDN Web Docs glossary'
url: 'https://developer.mozilla.org/en-US/docs/Glossary/API'
- name: 'OpenAPI Specification'
url: 'https://spec.openapis.org/oas/latest.html'
- name: 'RFC 9110 — HTTP Semantics'
url: 'https://www.rfc-editor.org/rfc/rfc9110'
- name: 'RFC 6749 — OAuth 2.0 Authorization Framework'
url: 'https://www.rfc-editor.org/rfc/rfc6749'
- name: 'API — Wikipedia'
url: 'https://en.wikipedia.org/wiki/API'
cta:
title: 'Seu backend, já como API'
text: 'Defina um modelo de dados no Back4app e a plataforma gera as APIs REST e GraphQL para ele — endpoints, autenticação e permissões incluídos — com SDKs que as falam de forma idiomática em todas as principais plataformas.'
linkText: 'Comece grátis'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-20'
translationKey: api
---
**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
| Pergunta | Resposta |
| --- | --- |
| A definição | Um contrato definido de requisição/resposta entre dois programas |
| O ciclo | Endpoint + método + headers + corpo → código de status + resposta |
| Por público | Pública · de parceiros · interna · composta |
| Por estilo | REST · GraphQL · gRPC · SOAP · WebSocket |
| O contrato moderno | Uma especificação legível por máquina (OpenAPI) que gera docs, clients e mocks |
## 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:
```text
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:**
```javascript
// 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
// 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}');
```
**Swift:**
```swift
// 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 ?? "")") }
}
```
**Kotlin:**
```kotlin
// 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
```mermaid
flowchart LR
accTitle: O ciclo de requisição e resposta de uma API
accDescr: Uma aplicação cliente envia uma requisição com método, endpoint, headers e corpo para uma API, que a valida e autoriza, invoca a lógica de backend e os dados, e retorna um código de status com um corpo de resposta ao cliente.
C["App cliente
(web, mobile, outro servidor)"] -->|"requisição:
método + endpoint + headers + corpo"| A["API
valida · autoriza · roteia"]
A --> B["Lógica de backend
+ banco de dados"]
B --> A
A -->|"resposta:
código de status + JSON"| C
```
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](/glossary/data-layer-vs-application-layer-security/) vivem na interface, e é por isso que clientes falam com APIs e nunca com [o banco de dados](/glossary/nosql-vs-sql/) 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](https://spec.openapis.org/oas/latest.html) é 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:**
| Tipo | Consumidores | Preocupações típicas |
| --- | --- | --- |
| Pública (aberta) | Qualquer desenvolvedor registrado | Chaves, cotas, qualidade da documentação, disciplina de versionamento |
| De parceiros | Empresas contratadas | Acordos jurídicos, SLAs, auth mais rígida |
| Interna (privada) | Seus próprios times e serviços | Contratos de microsserviços, ciclos de mudança mais rápidos |
| Composta | Clientes que precisam de pacotes | Uma chamada orquestrando várias — menos idas e vindas |
**Por estilo:** [REST](/glossary/pt/api-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](/glossary/websockets-real-time-sync/)) — 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
| Estilo | Formato no fio | Modelo | Mais forte em | Fique atento a |
| --- | --- | --- | --- | --- |
| REST | JSON sobre HTTP | Recursos + métodos | APIs CRUD públicas, cacheabilidade, ubiquidade | Over/underfetching em formatos fixos |
| GraphQL | JSON sobre HTTP | Consultas compostas pelo cliente | Clientes diversos, dados aninhados | Complexidade de cache, N+1 nos resolvers |
| gRPC | Protobuf sobre HTTP/2 | Chamadas de procedimento tipadas | Velocidade interna serviço a serviço | Atrito no navegador, debug binário |
| SOAP | Envelopes XML | Operações + padrões WS-* | Enterprise legado, contratos formais | Verbosidade, peso do ferramental |
| WebSocket | Frames sobre um socket | Mensagens bidirecionais | Push em tempo real, presença | Você define o protocolo por conta própria |
## 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
| Sua situação | Use |
| --- | --- |
| CRUD público sobre recursos | REST — a língua franca, amigável a cache |
| Muitos tipos de cliente, cada um com formatos diferentes | Selection sets do GraphQL |
| Malha interna de serviços de alto throughput | Contratos gRPC |
| Tempo real, bidirecional, sempre conectado | WebSocket (ou uma camada de live queries por cima) |
| Parceiro enterprise com exigências WS-* | SOAP — porque o contrato manda |
| Uma tela que precisa de cinco serviços | Um endpoint composto ou backend-for-frontend |
## 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](/glossary/api-rate-limiting-throttling/) 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](https://www.rfc-editor.org/rfc/rfc6749), 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](/glossary/overfetching-underfetching/).
## 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](/glossary/pt/apis-geradas-automaticamente/) — 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](/glossary/backend-sdk/) 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.