A requisição foi bem-sucedida.
Quando usar
Padrão para um GET bem-sucedido ou um POST que retorna um resultado.
Bom saber
A maior pegadinha do 200 é o “soft 404”: uma página de erro ou um resultado vazio servido com status 200. O Google detecta muitos deles e os sinaliza no Search Console, mas eles desperdiçam orçamento de rastreamento e podem manter URLs inúteis indexadas. Single-page apps são infratoras frequentes, porque o servidor retorna index.html com 200 para todo caminho; retorne um 404 de verdade para rotas desconhecidas ou adicione noindex.
APIs que embrulham erros em um 200 com um campo de erro quebram monitoramento, retentativas e cache, já que tudo parece bem-sucedido. Um 200 para GET pode ser armazenado por navegadores e CDNs, até heuristicamente quando só há Last-Modified, então defina Cache-Control explicitamente. Adicione um ETag ou Last-Modified para que os clientes possam revalidar e receber um 304 barato, e use 204 quando realmente não houver nada para retornar.
Sucesso (2xx)
Os códigos 2xx indicam sucesso: o servidor recebeu, entendeu e aceitou a requisição.
Como fica
HTTP/1.1 200 OKComo enviar
| Node.js / Express | res.status(200).end() |
|---|---|
| Python / Flask | return '', 200 |
| nginx | return 200; |
Como verificar
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/