O que é uma API

Uma API é o jeito de um programa pedir algo a outro programa. O nome vem de application programming interface (interface de programação de aplicações), o que diz muito pouco. Na prática, e no resto deste tutorial, uma API é um servidor que responde a requisições com dados em vez de páginas web.

Um app de previsão do tempo no seu celular não guarda as previsões. Quando você o abre, ele manda uma requisição para um servidor em algum lugar, recebe uns poucos kilobytes de temperaturas e velocidades do vento e desenha isso na tela. A parte do servidor é a API. O app é um dos clientes dela.

A sua primeira requisição

Cole este endereço na barra de endereços do navegador e aperte Enter:

https://api.testingapis.com/api/Products/1

Você recebe algo assim:

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

O seu navegador mandou uma requisição para um servidor. O servidor procurou o produto número 1 e devolveu uma descrição dele. Essa troca, uma requisição e uma resposta, é ao que toda interação com uma API se resume. O resto deste tutorial trata dos detalhes dessa troca e de como conferir se o servidor faz tudo certo.

Você também pode enviar a requisição a partir desta página. O botão Enviar abaixo faz o mesmo que o seu navegador acabou de fazer e mostra o status da resposta acima do corpo. Você vai ver esses botões ao longo das lições.

Clientes e servidores

O programa que envia a requisição é o cliente. O programa que responde é o servidor. Um cliente pode ser um navegador, um app de celular, outro servidor, uma ferramenta de linha de comando ou um teste que você escreveu. O servidor não consegue diferenciá-los, e nem precisa. Ele lê a requisição, faz o seu trabalho e responde.

Isso importa para os testes. Como o servidor trata todo cliente do mesmo jeito, você pode testá-lo sem o app que normalmente conversa com ele. Você não precisa passar por cinco telas de um app de compras para ver se o preço do produto está certo. Você pede o produto à API e olha o preço.

Endpoints

O endereço que você abriu tem duas partes. https://api.testingapis.com é a URL base: diz com qual servidor falar. /api/Products/1 é o caminho: diz o que você quer desse servidor. Cada caminho que o servidor entende se chama endpoint. Esta API tem algumas centenas. Alguns exemplos:

Você descobre quais endpoints existem na documentação da API. Para esta API, é a referência da API. Projetos reais variam muito aqui. Alguns têm documentação caprichada, outros um arquivo OpenAPI gerado a partir do código, e outros uma mensagem num canal de chat do desenvolvedor que a escreveu. Parte do trabalho de quem testa é perceber quando a documentação e a API discordam.

Quando a resposta é não

Agora peça um produto que não existe:

O servidor responde:

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

Esta também é uma resposta correta. Não existe o produto 9999, e o servidor diz isso com clareza: um status 404, que significa "não encontrado", e uma mensagem explicando qual ID estava faltando. Uma boa API cuida tanto das requisições que não consegue atender quanto das que consegue. Boa parte do teste de API acontece aqui, no caminho infeliz, porque é onde os desenvolvedores gastam menos tempo e onde está a maioria dos bugs.

Por que testar no nível da API

Você poderia testar tudo pelas telas do app. As equipes testam APIs diretamente por alguns motivos práticos.

• É mais rápido. Uma requisição leva milissegundos. Chegar ao mesmo estado clicando numa interface leva segundos, e automatizar esses cliques demora muito mais para escrever e quebra toda vez que um botão muda de lugar.
• A API costuma existir primeiro. Backend e frontend muitas vezes são construídos em paralelo, então você pode começar a testar o backend antes de existir qualquer coisa para clicar.
• A interface esconde problemas. Digamos que o campo de quantidade de um app de compras só aceite números de 1 a 10. A API por trás recebe uma requisição comum, e qualquer pessoa pode mandar uma com quantidade -5. Se o servidor confia que o app já conferiu, o pedido passa com um total negativo. Você só descobre isso falando diretamente com a API.
• Uma API costuma atender vários clientes: um site, um app de iPhone, um app de Android, uma integração com um parceiro. Um bug na API é um bug em todos eles.

Testes de interface continuam tendo o seu lugar. Eles são o único jeito de conferir se as telas funcionam. Mas as regras do sistema (quem pode ver o quê, como é um pedido válido, o que acontece quando o estoque acaba) moram na API, então é lá que você as confere.