Skip to content
ENPT

Código de status HTTP · Sucesso (2xx)

200 OK

O 200 OK significa que o pedido deu certo e a resposta traz o resultado: a página ou os dados num GET, o resultado da ação num POST. É o status que quase todo framework envia por padrão quando o handler retorna sem definir outro.

Dados sobre este código de status
Classe2xx, Sucesso
Definido emRFC 9110 §15.3.1
Pode ir para o cache por padrãoSim, de forma heurística; em GET e HEAD; envie ETag ou Last-Modified para os caches poderem revalidar
Pode repetir o pedidoNão é preciso; o pedido deu certo
Cabeçalhos relevantes
  • ETag: a RFC 9110 diz que um 200 para GET ou HEAD DEVE trazer validadores; permite 304 depois
  • Cache-Control: use private ou no-store em respostas por usuário para caches compartilhados não reaproveitarem

O que significa o 200

A RFC 9110, seção 15.3.1, liga o significado do corpo ao método: no GET é o recurso, no HEAD os mesmos cabeçalhos sem corpo, no POST o resultado da ação, no PUT e no DELETE a situação da ação. No CONNECT um 200 indica que o túnel está aberto e não tem corpo.

O 200 pode ser armazenado em cache de forma heurística, então navegador ou CDN podem reaproveitá-lo sem perguntar de novo, a menos que o Cache-Control diga o contrário. Para GET e HEAD a especificação pede validadores, de preferência um ETag forte e o Last-Modified, e é isso que permite que os próximos pedidos recebam um 304 barato em vez do corpo inteiro.

O 200 só diz que a troca HTTP funcionou. Muitos sistemas devolvem 200 com um erro dentro: servidores GraphQL colocam falhas num array errors, algumas APIs embrulham tudo em { "success": false } e sites mal configurados servem a página de "não encontrado" com 200. Um monitoramento que só olha o status vai achar tudo isso saudável.

Quando usar

  • GET que devolve o recurso ou uma lista, mesmo que vazia.
  • POST que executa uma ação sem criar um recurso com URL própria: uma busca, um cálculo, um login que devolve um token.
  • PUT ou PATCH que devolve o recurso atualizado no corpo (use 204 se não devolver nada).

Causas comuns

Se você está visitando o site

  • A página dá 200 mas mostra conteúdo antigo: o DevTools indica "(disk cache)" ou "(memory cache)", ou seja, o navegador nem consultou o servidor.

Se você administra o servidor

  • Página em branco com status 200: o HTML carregou, mas o bundle JavaScript deu erro, então o problema está no console, não na rede.
  • Uma página de erro, um resultado vazio ou um login recusado sai com 200, e clientes, buscadores e monitores de uptime entendem como sucesso.
  • Um usuário vê dados de outro: uma CDN guardou um 200 personalizado porque faltava Cache-Control: private.

Como resolver

Se você está visitando o site

  • Recarregue forçado com Ctrl+Shift+R (Cmd+Shift+R no macOS) para ignorar a cópia em cache.

Se você administra o servidor

  • Devolva o status que corresponde ao resultado: 404 para ausente, 401 ou 403 para falha de acesso, 422 para dados inválidos.
  • Marque respostas por usuário com Cache-Control: private, no-store e versione os arquivos estáticos para que max-age longo seja seguro.
  • Aponte o monitor de uptime para um endpoint de saúde que só responde 200 quando as dependências respondem.

Como enviar um 200

Express (Node.js)
app.get('/reports/:id', (req, res) => {
  res.status(200).json({ id: '42', title: 'Q3 revenue' });
});
Next.js App Router (route handler)
// app/reports/[id]/route.ts
export async function GET() {
  return Response.json({ id: '42', title: 'Q3 revenue' }, { status: 200 });
}
Go net/http
mux.HandleFunc("GET /reports/{id}", func(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(http.StatusOK) // 200
	w.Write([]byte(`{"id":"42","title":"Q3 revenue"}`))
})
Python FastAPI
from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()

@app.get("/reports/{id}")
def get_report(id: str):
    return JSONResponse(status_code=200, content={"id": "42", "title": "Q3 revenue"})
Nginx
# Health check answered by nginx itself
location = /healthz {
  access_log off;
  default_type text/plain;
  return 200 "ok\n";
}

Costuma ser confundido com

200 vs 201
O 201 Created diz que um novo recurso passou a existir (e onde, via Location); o 200 num POST só diz que a ação funcionou.
200 vs 204
O 204 No Content é um sucesso sem nada no corpo; do 200 se espera que traga conteúdo.
200 vs 304
O 304 indica que o navegador perguntou e o servidor confirmou que a cópia em cache ainda vale; "200 (from cache)" indica que o navegador nem perguntou.

Perguntas frequentes

Status 200 OK sempre significa sucesso?
Significa que o pedido HTTP deu certo, não necessariamente a sua operação. Algumas APIs e servidores GraphQL devolvem 200 com um erro no corpo, então confira também o formato de resposta que a API documenta.
O que significa "200 (from disk cache)" no DevTools?
O navegador reaproveitou uma cópia guardada sem falar com o servidor, porque a resposta em cache ainda estava válida pelo Cache-Control ou pela validade heurística. Nenhum pedido saiu da sua máquina.
Um POST deve responder 200 ou 201?
Responda 201 Created quando o POST cria um recurso com URL própria, e inclua Location. Responda 200 quando ele executa uma ação ou devolve um resultado calculado sem criar nada endereçável.
Uma resposta 200 pode ter corpo vazio?
Pode, com Content-Length: 0, mas a RFC 9110 espera que o 200 traga conteúdo e recomenda o 204 No Content quando não há nada a devolver de propósito.

Revisado em por Arielton Oberek.