---
term: 'SDK de Backend'
seoTitle: 'O que é um SDK de Backend? Diferença entre SDK e API'
headline: 'O que é um SDK de backend?'
slug: sdk-de-backend
category: api-realtime
shortDefinition: 'Um SDK de backend é um kit de bibliotecas e utilitários que permite que apps falem com um serviço de backend na própria linguagem, sem HTTP bruto.'
relatedTerms:
  - baas-vs-custom-backend
  - auto-generated-database-apis
  - database-abstraction-layer
  - backend-boilerplate-code
contrastsWith:
  - auto-generated-database-apis
faq:
  - question: 'O que é um SDK, em termos simples?'
    answer: 'Um software development kit: o pacote de bibliotecas, documentação e ferramentas que torna prático construir sobre uma plataforma. Um SDK de backend é o membro client-side da família — a biblioteca que transforma a API HTTP de um serviço de backend em métodos nativos e objetos tipados na linguagem do seu app.'
  - question: 'Qual é a diferença entre um SDK e uma API?'
    answer: 'A API é o contrato — os endpoints, parâmetros e respostas que um serviço expõe. O SDK é o kit que fala esse contrato por você: métodos nativos que montam as requisições, anexam a autenticação, parseiam respostas em objetos tipados e tratam erros. Sempre dá para usar uma API sem o SDK dela; o SDK existe para que você raramente queira.'
  - question: 'O que um SDK de backend faz de fato por baixo dos panos?'
    answer: 'O trabalho braçal que você escreveria a cada chamada: compor a URL e codificar parâmetros, anexar as chaves do app e o token de sessão do usuário, serializar e desserializar entre objetos nativos e JSON, mapear erros HTTP para exceções tipadas, fazer retries com bom senso e manter o estado da sessão entre chamadas. Uma chamada de método na sua linguagem; uma troca HTTP correta e autenticada por baixo.'
  - question: 'Qual é a diferença entre um SDK de cliente e um SDK de servidor?'
    answer: 'Confiança. Um SDK de cliente é distribuído dentro de apps nas mãos dos usuários, então carrega só chaves publicáveis, e cada requisição é checada contra permissões no servidor. Um SDK de servidor roda em ambientes que você controla e pode guardar credenciais privilegiadas que passam por cima dessas checagens. Confundir os dois — embarcar uma chave privilegiada em um app — é a falha de segurança clássica de SDK.'
  - question: 'Qual é a diferença entre SDK, biblioteca e framework?'
    answer: 'Uma biblioteca é código que você chama; um framework é código que chama você, ditando a estrutura. Um SDK é um kit — tipicamente uma ou mais bibliotecas mais documentação, ferramentas e exemplos — voltado a uma plataforma ou serviço. Todo SDK contém bibliotecas; nem toda biblioteca é um SDK; frameworks invertem o controle de um jeito que nenhum dos dois faz.'
  - question: 'Quando usar HTTP bruto em vez do SDK?'
    answer: 'Quando o SDK não cabe no ambiente: uma linguagem sem suporte, restrições extremas de tamanho de binário, runtimes de edge onde cada dependência conta, ou um SDK abandonado que ficou para trás da API. HTTP bruto é sempre possível contra uma API documentada — você herda de volta o trabalho braçal que o SDK absorvia, então faça disso uma troca deliberada, não um padrão.'
  - question: 'O que faz um SDK ser bom?'
    answer: 'Ele parece nativo em cada linguagem em vez de traduzido por máquina; é tipado, documentado e atualizado com a API; os erros são acionáveis; auth e retries são invisíveis; e seu footprint é proporcional. O teste são os primeiros dez minutos: um bom SDK leva você da instalação à primeira chamada bem-sucedida em uma tela de código.'
  - question: 'Plataformas de backend precisam de um SDK por plataforma?'
    answer: 'As sérias entregam uma família — web, as plataformas mobile e as linguagens de servidor comuns — porque cada ecossistema espera seus próprios idiomas, padrões de async e sistemas de tipos. Cobertura é um critério real de seleção: a API da plataforma é tão usável quanto o SDK para a plataforma em que você está construindo.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Software development kit (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Software_development_kit'
  - name: 'SDK documentation hub'
    url: 'https://docs.parseplatform.org/'
  - name: 'JavaScript SDK guide'
    url: 'https://docs.parseplatform.org/js/guide/'
  - name: 'Back4app SDK quickstarts'
    url: 'https://www.back4app.com/docs'
cta:
  title: 'Um backend, nativo em todo lugar'
  text: 'O Back4app entrega SDKs open-source para JavaScript, Flutter, Swift, Kotlin e mais — objetos tipados, gestão de sessão, queries, arquivos e atualizações ao vivo como idiomas nativos em cada plataforma, todos falando com o mesmo backend.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-24'
translationKey: backend-sdk
---

**Um SDK de backend é um kit de bibliotecas e utilitários que permite que apps falem com um serviço de backend na própria linguagem, sem HTTP bruto.** A API é o contrato; o SDK é seu falante fluente — e a diferença entre os dois se mede no código de infraestrutura que o seu app deixa de conter.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| SDK vs. API | API = o contrato; SDK = o kit que o fala nativamente |
| O que ele absorve | URLs, headers de auth, serialização, erros, retries, estado de sessão |
| SDK de cliente vs. de servidor | Chaves publicáveis + permissões impostas vs. código confiável privilegiado |
| vs. biblioteca/framework | Um kit de bibliotecas para uma plataforma; frameworks invertem o controle |
| Critérios de seleção | Cobertura de linguagens, tipagem, cadência de manutenção, velocidade até a primeira chamada |

## O trabalho braçal, antes e depois

O que uma query custa em HTTP bruto:

```javascript
// HTTP bruto: cada chamada reimplementa o trabalho braçal
const res = await fetch(
  'https://parseapi.back4app.com/classes/Order?where=' +
    encodeURIComponent(JSON.stringify({ status: 'paid' })),
  {
    headers: {
      'X-Parse-Application-Id': APP_ID,
      'X-Parse-REST-API-Key': REST_KEY,
      'X-Parse-Session-Token': sessionToken,   // obtido e armazenado… por você
    },
  }
);
if (!res.ok) handleHttpError(res.status);       // mapeado para o quê, exatamente?
const orders = (await res.json()).results.map(hydrateOrder); // tipagem: por sua conta
```

A mesma chamada pelo SDK — com sessão, serialização e erros tratados por dentro:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// One SDK call — session auth, serialization, retries all inside it
const query = new Parse.Query('Order');
query.equalTo('status', 'paid');
const orders = await query.find();
// The raw-HTTP version of this: build the URL, attach headers and
// session token, encode the where-clause, parse JSON, map types…
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// One SDK call — session auth, serialization, retries all inside it
final query = QueryBuilder<ParseObject>(ParseObject('Order'))
  ..whereEqualTo('status', 'paid');
final response = await query.query();
// Typed objects out; headers, tokens, and JSON handled inside the SDK
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// One SDK call — session auth, serialization, retries all inside it
let query = Order.query("status" == "paid")
query.find { result in
  if case .success(let orders) = result {
    render(orders)   // typed structs out; HTTP plumbing inside the SDK
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// One SDK call — session auth, serialization, retries all inside it
val query = ParseQuery.getQuery<ParseObject>("Order")
query.whereEqualTo("status", "paid")
query.findInBackground { orders, e ->
  if (e == null) render(orders) // typed objects out; plumbing inside the SDK
}
```

## Onde o SDK se encaixa

```mermaid
flowchart LR
  accTitle: Como um SDK de backend conecta um app a um serviço
  accDescr: O código da aplicação chama métodos nativos do SDK; o SDK compõe requisições HTTP autenticadas para a API do serviço de backend e parseia as respostas de volta em objetos tipados para o app.
  A["Código do app<br/>métodos nativos, objetos tipados"] --> S["SDK<br/>auth · serialização ·<br/>erros · retries · sessão"]
  S -->|"HTTPS"| API["API de backend<br/>REST / GraphQL"]
  API --> B["Serviço de backend"]
```

## SDK vs. API vs. biblioteca vs. framework

| Conceito | O que é | Quem chama quem | Formato típico |
| --- | --- | --- | --- |
| API | O contrato do serviço na rede | Você a chama (de algum jeito) | Endpoints + JSON |
| **SDK** | **Kit que fala o contrato em uma plataforma** | **Você o chama, nativamente** | **Biblioteca + docs + ferramentas** |
| Biblioteca | Código reutilizável para uma tarefa | Você a chama | Um pacote de parsing de datas |
| Framework | Estrutura que executa o seu código | Ele chama você | Um framework web ou de UI |

E a distinção que carrega o peso de segurança — **SDK de cliente vs. SDK de servidor**:

| Dimensão | SDK de cliente | SDK de servidor |
| --- | --- | --- |
| Roda onde | Dispositivos e navegadores dos usuários | Infraestrutura que você controla |
| Credenciais | Só chaves publicáveis de app | Pode guardar chaves privilegiadas |
| Permissões | Impostas no servidor a cada requisição (ACLs, CLPs) | Pode ser confiável para ignorá-las |
| Regra de ouro | **Nada secreto embarca nele** | **Suas chaves nunca saem do servidor** |

A brecha clássica neste vocabulário: uma chave privilegiada de servidor colada em um app mobile "temporariamente". SDKs de cliente são projetados sob a premissa de que tudo neles é público — e é por isso que a segurança de verdade mora na [camada de dados](/glossary/pt/seguranca-camada-de-dados-vs-aplicacao/), não no binário.

## Casos de uso comuns

- **Apps mobile e web em um BaaS** — o SDK *é* a interface do backend: auth, dados, arquivos e atualizações ao vivo como chamadas nativas.
- **Consumo de serviços de terceiros** — pagamentos, mensageria, analytics: o SDK do fornecedor poupa você dos detalhes de HTTP dele.
- **Integração servidor-a-serviço** — SDKs de servidor com credenciais privilegiadas fazendo trabalho administrativo em ambientes confiáveis.
- **Produtos multiplataforma** — um backend, quatro SDKs, quatro idiomas nativos — as abas de código acima são uma query em quatro ecossistemas.
- **Times internos de plataforma** — embrulhar suas próprias APIs em SDKs finos para que os times de produto nunca reescrevam o trabalho braçal duas vezes.

## SDK ou HTTP bruto? Matriz de decisão

| Use o SDK quando… | Vá de HTTP bruto quando… |
| --- | --- |
| Sua plataforma é coberta e mantida | A linguagem não tem SDK (vivo) |
| Auth e gestão de sessão importam | É uma chamada única sem autenticação |
| Você quer objetos e erros tipados | O tamanho do binário se conta em kilobytes |
| O time varia em nível de experiência | Você está construindo a *sua própria* camada de SDK |
| Velocidade vence controle | O SDK está atrás da API de que você precisa hoje |

O enquadramento honesto: HTTP bruto está sempre disponível contra uma API documentada — o SDK é uma conveniência com retornos compostos, não uma trava. Prefira plataformas em que os SDKs são open source, para a conveniência nunca virar caixa-preta.

## Limitações e trade-offs

- **Um SDK é uma dependência com ciclo de vida.** Versões, breaking changes e depreciações chegam no cronograma do fornecedor; fixe versões, leia changelogs e prefira publicadores disciplinados com semver.
- **Abstração esconde a rede.** Quando algo se comporta mal, você depura através da camada do SDK — os bons logam; os ótimos são open source, para você poder ler a verdade.
- **Cobertura é desigual.** O SDK da linguagem-vitrine costuma ser excelente enquanto a cauda longa atrasa; avalie o SDK da *sua* plataforma, não os screenshots da documentação.
- **Peso de bundle é real em clientes.** Orçamentos de mobile e web se importam com kilobytes; SDKs modulares e tree-shakeable merecem seu lugar.
- **O SDK não conserta a API.** Um contrato confuso produz um kit confuso — a qualidade do SDK é jusante do design da API.

## SDKs 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. A família de SDKs é a porta de entrada: [kits open-source](https://docs.parseplatform.org/) para JavaScript, Flutter, Swift, Kotlin/Android e mais, cada um embrulhando as mesmas APIs geradas com idiomas nativos — objetos com tipagem segura (type-safe), gestão de sessão, queries com includes, upload de arquivos e assinaturas ao vivo. SDKs de cliente carregam só chaves publicáveis, com ACLs e permissões de classe impostas no servidor a cada chamada; o trabalho privilegiado fica no Cloud Code. Um backend, todas as plataformas, nenhum trabalho braçal nos seus repositórios.