As respostas HTTP são uma parte importante da comunicação web, permitindo que servidores respondam às solicitações de clientes com os dados solicitados, informações de status e outros detalhes essenciais. Este artigo explicará a estrutura e as partes de uma resposta HTTP, incluindo a linha de status, cabeçalhos e corpo. Vamos analisar os diferentes grupos de códigos de status HTTP e seus significados, com exemplos reais para mostrar como são usados. Também falaremos sobre boas práticas para lidar com respostas HTTP no desenvolvimento web, tanto no lado do cliente quanto no lado do servidor, para garantir que clientes e servidores possam se comunicar bem.
Principais Pontos
- Uma resposta HTTP é a mensagem que um servidor web envia de volta a um cliente após receber e processar uma solicitação HTTP.
- Os componentes principais de uma resposta HTTP incluem a linha de status, cabeçalhos e corpo opcional contendo o conteúdo solicitado.
- Os códigos de status HTTP são categorizados em respostas informativas (1xx), respostas de sucesso (2xx), mensagens de redirecionamento (3xx), respostas de erro do cliente (4xx) e respostas de erro do servidor (5xx).
- No lado do cliente, é importante verificar os códigos de status, processar os dados de resposta com base no cabeçalho Content-Type e lidar adequadamente com redirecionamentos e erros.
- No lado do servidor, definir os códigos de status e cabeçalhos corretos, fornecer mensagens de erro claras e implementar tratamento de erros e registro adequados são essenciais para o desenvolvimento web.
O Que É uma Resposta HTTP?
Uma resposta HTTP é a mensagem que um servidor web envia de volta a um cliente após receber e processar uma solicitação HTTP. Ela entrega o resultado da solicitação do cliente, seja esse resultado um sucesso, uma falha ou algo intermediário. A resposta inclui informações de status sobre a solicitação e também pode ter conteúdo em seu corpo, como o recurso solicitado (uma página web, imagem, dados JSON, etc.) ou uma mensagem de erro.
As respostas HTTP são necessárias para que um cliente entenda se sua solicitação foi bem-sucedida ou não e qual foi o resultado dessa solicitação. Os navegadores web usam respostas HTTP para saber qual conteúdo exibir aos usuários. As APIs usam respostas HTTP para indicar o resultado de operações e para enviar dados de volta. A estrutura e o conteúdo da resposta HTTP determinam como o cliente prossegue.
Componentes de uma Resposta HTTP
Uma resposta HTTP consiste em vários componentes principais:
- Linha de Status: A primeira linha da resposta, que inclui a versão HTTP, um código de status e uma mensagem de status.
- Cabeçalhos: Pares chave-valor que fornecem informações adicionais sobre a resposta, como o tipo de conteúdo, comprimento do conteúdo, diretivas de cache e muito mais.
- Corpo (opcional): O conteúdo real da resposta, como HTML, JSON, uma imagem, etc.
Aqui está um exemplo de uma resposta HTTP simples:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<!DOCTYPE html>
<html>
<head>
<title>Página de Exemplo</title>
</head>
<body>
<h1>Olá, Mundo!</h1>
<p>Esta é uma página de exemplo.</p>
</body>
</html>
Exemplos Reais
Navegação Web: Quando você digita uma URL no seu navegador web, ele envia uma solicitação HTTP ao servidor. O servidor então responde com uma resposta HTTP que inclui o conteúdo HTML da página web. Seu navegador usa essa resposta para renderizar a página.
Interação com API: Quando um aplicativo faz uma solicitação a um endpoint de API, o servidor da API responde com uma resposta HTTP. Esta resposta geralmente inclui dados JSON que o aplicativo pode usar. Por exemplo, um aplicativo de clima pode fazer uma solicitação a uma API de clima e receber dados meteorológicos atuais na resposta.
Download de Arquivo: Quando você clica em um link para baixar um arquivo, seu navegador envia uma solicitação HTTP ao servidor. O servidor responde com uma resposta HTTP que inclui os dados do arquivo no corpo e cabeçalhos que indicam o tipo e tamanho do arquivo.
Componentes de uma Resposta HTTP
Uma resposta HTTP possui várias partes principais que fornecem informações sobre o resultado da solicitação e entregam os dados solicitados.
Linha de Status
A linha de status é a primeira linha da resposta HTTP. Ela inclui:
- Versão HTTP: Mostra a versão do protocolo HTTP usada, como HTTP/1.1 ou HTTP/2.
- Código de Status: Um número de três dígitos que indica o resultado da solicitação, como 200 para sucesso, 404 para "não encontrado" ou 500 para erro do servidor.
- Texto de Status: Uma breve descrição do código de status, como "OK" para 200, "Not Found" para 404 ou "Internal Server Error" para 500.
Aqui estão alguns códigos de status HTTP comuns e seus significados:
| Código de Status | Texto de Status | Significado |
|---|---|---|
| 200 | OK | A solicitação foi bem-sucedida e o corpo da resposta contém os dados. |
| 201 | Created | A solicitação foi bem-sucedida e um novo recurso foi criado. |
| 301 | Moved Permanently | O recurso solicitado foi permanentemente movido para uma nova URL. |
| 400 | Bad Request | O servidor não conseguiu entender a solicitação devido à sintaxe inválida. |
| 401 | Unauthorized | A solicitação requer autenticação do usuário. |
| 404 | Not Found | O servidor não conseguiu encontrar o recurso solicitado. |
| 500 | Internal Server Error | O servidor encontrou um erro inesperado. |
O código de status HTTP faz parte da mensagem de resposta. Ele define a classe da resposta e desempenha um papel de categorização. O primeiro dígito do código de status indica o tipo de resposta:
- 1xx: Resposta informativa
- 2xx: Sucesso
- 3xx: Redirecionamento
- 4xx: Erro do cliente
- 5xx: Erro do servidor
Os códigos de status HTTP são extensíveis, mas as aplicações HTTP não são obrigadas a entender o significado de todos os códigos de status registrados. Informações adicionais sobre a resposta podem ser encontradas nos campos de cabeçalho da resposta.
Cabeçalhos de Resposta
Após a linha de status estão os cabeçalhos de resposta. Estes são pares chave-valor que fornecem mais detalhes sobre a resposta. Alguns cabeçalhos comuns incluem:
- Server: O tipo de servidor que gerou a resposta, como "Apache/2.4.41 (Ubuntu)".
- Content-Type: O tipo MIME dos dados no corpo da resposta, como "text/html" para HTML ou "application/json" para JSON.
- Content-Length: O tamanho do corpo da resposta em bytes.
- Cache-Control: Direções para mecanismos de cache, especificando se a resposta pode ser armazenada em cache, por quanto tempo, etc. Por exemplo, "max-age=3600" significa que a resposta pode ser armazenada em cache por uma hora.
- Set-Cookie: Envia cookies do servidor para o cliente, como "session_id=abc123; Expires=Wed, 21 Jun 2023 07:28:00 GMT".
Linha em Branco
Após os cabeçalhos, há uma linha em branco. Esta linha vazia sinaliza o fim da seção de cabeçalhos da resposta.
Corpo da Resposta
Após a linha em branco está o corpo da resposta. Este contém os dados reais que foram solicitados, como:
Um arquivo HTML para uma página web:
<!DOCTYPE html> <html> <head> <title>Página de Exemplo</title> </head> <body> <h1>Bem-vindo à Página de Exemplo</h1> <p>Este é um exemplo de corpo de resposta HTML.</p> </body> </html>Dados JSON para uma resposta de API:
{ "name": "João Silva", "age": 30, "city": "São Paulo" }Uma imagem, vídeo ou outro arquivo de mídia.
Um arquivo para download, como um PDF ou arquivo ZIP.
Se a resposta indica um erro, como um código de status 404 ou 500, o corpo pode conter uma mensagem de erro fornecendo mais detalhes sobre o problema, como:
<!DOCTYPE html>
<html>
<head>
<title>404 Não Encontrado</title>
</head>
<body>
<h1>404 Não Encontrado</h1>
<p>O recurso solicitado não pôde ser encontrado neste servidor.</p>
</body>
</html>
O corpo da resposta é opcional. Para algumas solicitações, como uma solicitação HEAD ou uma resposta 204 "No Content", não haverá corpo.
Categorias de Códigos de Status de Resposta HTTP
Os códigos de status de resposta HTTP são divididos em cinco categorias com base em seu primeiro dígito. Cada categoria representa uma classe diferente de respostas.
Respostas informativas (100-199)
Códigos de status na faixa de 100-199 significam que o servidor recebeu a solicitação e está processando-a. Estes códigos são respostas. Alguns códigos de status informativos comuns incluem:
| Código de Status | Descrição |
|---|---|
100 Continue |
O servidor recebeu os cabeçalhos da solicitação e o cliente deve enviar o corpo da solicitação. |
102 Processing |
O servidor recebeu e está processando a solicitação, mas ainda não há resposta disponível. |
Exemplo de cenário:
- Um cliente envia uma solicitação POST com uma grande carga útil. O servidor responde com um código de status
100 Continuepara informar ao cliente que envie o corpo da solicitação.
Respostas de sucesso (200-299)
Códigos de status na faixa de 200-299 significam que o servidor recebeu, entendeu e aceitou a solicitação. Alguns códigos de status de sucesso comuns incluem:
| Código de Status | Descrição |
|---|---|
200 OK |
A solicitação foi bem-sucedida e o corpo da resposta contém os dados solicitados. |
201 Created | A solicitação foi bem-sucedida e um novo recurso foi criado. Isso é comumente usado como resposta a uma solicitação POST. |
204 No Content |
O servidor atendeu à solicitação mas não precisa retornar nenhum conteúdo. |
Exemplos de cenários:
- Um cliente solicita uma página web usando uma solicitação GET. O servidor responde com um código de status
200 OKe retorna o conteúdo HTML. - Um cliente envia um formulário para criar um novo recurso usando uma solicitação POST. O servidor cria o recurso e responde com um código de status
201 Created. - Um cliente envia uma solicitação DELETE para remover um recurso. O servidor exclui o recurso e responde com um código de status
204 No Content.
Mensagens de redirecionamento (300-399)
Códigos de status na faixa de 300-399 significam que o cliente precisa tomar mais ações para completar a solicitação. A ação pode ser feita pelo agente do usuário sem interação com o usuário. Alguns códigos de status de redirecionamento comuns incluem:
| Código de Status | Descrição |
|---|---|
301 Moved Permanently |
O recurso solicitado recebeu uma nova URI permanente e referências futuras devem usar uma das URIs retornadas. |
302 Found |
O recurso solicitado está em uma URI diferente. O cliente deve continuar a usar a Request-URI para solicitações futuras. |
304 Not Modified |
O recurso não foi modificado desde a versão especificada pelos cabeçalhos da solicitação, então o cliente pode continuar a usar a versão em cache. |
Exemplos de cenários:
- Um cliente solicita um recurso que foi permanentemente movido para uma nova URL. O servidor responde com um código de status
301 Moved Permanentlye inclui a nova URL no cabeçalhoLocation. - Um cliente solicita um recurso que está em uma URL diferente. O servidor responde com um código de status
302 Founde inclui a URL temporária no cabeçalhoLocation. - Um cliente envia uma solicitação GET condicional com cabeçalho
If-Modified-Since. Se o recurso não foi modificado desde a data especificada, o servidor responde com um código de status304 Not Modified.
Respostas de erro do cliente (400-499)
Códigos de status na faixa de 400-499 significam que o cliente parece ter cometido um erro. Exceto ao responder a uma solicitação HEAD, o servidor deve incluir uma entidade explicando o erro. Alguns códigos de status de erro do cliente comuns incluem:
| Código de Status | Descrição |
|---|---|
400 Bad Request |
O servidor não conseguiu entender a solicitação devido à sintaxe incorreta. |
401 Unauthorized |
A solicitação requer autenticação do usuário. |
404 Not Found |
O servidor não encontrou nada correspondente à Request-URI. |
Exemplos de cenários:
- Um cliente envia uma solicitação com parâmetros inválidos ou ausentes. O servidor responde com um código de status
400 Bad Requeste inclui uma mensagem de erro no corpo da resposta. - Um cliente tenta acessar um recurso protegido sem fornecer autenticação válida. O servidor responde com um código de status
401 Unauthorizede solicita que o cliente se autentique. - Um cliente solicita um recurso que não existe no servidor. O servidor responde com um código de status
404 Not Found.
Respostas de erro do servidor (500-599)
Códigos de status na faixa de 500-599 significam que o servidor sabe que cometeu um erro ou não consegue realizar a solicitação. Exceto ao responder a uma solicitação HEAD, o servidor deve incluir uma entidade explicando o erro, e se é uma condição temporária ou permanente. Alguns códigos de status de erro do servidor comuns incluem:
| Código de Status | Descrição |
|---|---|
500 Internal Server Error |
O servidor encontrou uma condição inesperada que o impediu de atender à solicitação. |
503 Service Unavailable |
O servidor não consegue atender à solicitação no momento devido a uma sobrecarga temporária ou manutenção do servidor. |
504 Gateway Timeout |
O servidor, atuando como gateway ou proxy, não recebeu uma resposta oportuna do servidor upstream que precisava acessar para completar a solicitação. |
Exemplos de cenários:
- Um cliente solicita um recurso, mas ocorre um erro inesperado no lado do servidor. O servidor responde com um código de status
500 Internal Server Errore registra o erro para investigação. - Um cliente tenta acessar um serviço que está temporariamente fora do ar para manutenção. O servidor responde com um código de status
503 Service Unavailablee pode incluir um cabeçalhoRetry-Afterpara indicar quando o serviço estará disponível novamente. - Um cliente solicita um recurso que requer que o servidor se comunique com um servidor upstream. Se o servidor upstream demora muito para responder, o servidor envia um código de status
504 Gateway Timeoutao cliente.
Para mais informações sobre códigos de status HTTP, você pode consultar os seguintes recursos:
Lidando com Respostas HTTP no Desenvolvimento Web
Ao criar aplicações web, você precisa lidar corretamente com respostas HTTP tanto no lado do cliente quanto no lado do servidor. Isso ajuda a proporcionar uma boa experiência ao usuário e facilita a depuração e manutenção da aplicação.
Lado do Cliente
No lado do cliente, como em um navegador web ou aplicativo móvel, você precisa:
Verificar códigos de status: Após enviar uma solicitação HTTP, o cliente deve verificar o código de status HTTP da resposta para ver se a solicitação funcionou ou não. Por exemplo:
Código de Status Significado 200 OK Sucesso 404 Recurso solicitado não encontrado Processar dados de resposta: Com base no código de status e no campo de cabeçalho
Content-Type, o cliente precisa processar o corpo da resposta da maneira correta. Por exemplo:Content-Type Ação HTML Navegador irá renderizá-lo JSON Analisar em um objeto para uso posterior Lidar com redirecionamentos e erros: Se o código de status significa um redirecionamento (códigos 3xx), o cliente deve seguir a nova URL no cabeçalho
Location. Para códigos de erro do cliente (4xx) e erro do servidor (5xx), o cliente deve mostrar mensagens de erro ao usuário e talvez tentar novamente a solicitação ou pedir que o usuário faça algo.
Exemplo de como lidar com uma mensagem de resposta HTTP em JavaScript usando a Fetch API:
fetch('https://api.example.com/data')
.then(response => {
if (!response.ok) {
throw new Error(`Erro HTTP! status: ${response.status}`);
}
return response.json();
})
.then(data => {
console.log(data);
// Processar os dados
})
.catch(error => {
console.error('Erro:', error);
// Lidar com o erro
});
Lado do Servidor
No lado do servidor, você precisa:
Definir os códigos de status e cabeçalhos corretos: Ao enviar uma resposta, o servidor web deve definir o código de status HTTP correto para mostrar o resultado do processamento da solicitação. Ele também deve incluir campos de cabeçalho de resposta, como
Content-Type, para ajudar o cliente a entender a resposta corretamente.Fornecer mensagens de erro claras: Para respostas de erro do cliente e do servidor, o servidor deve incluir uma mensagem de erro clara e concisa no corpo da resposta. Isso ajuda os desenvolvedores a saber o que deu errado e como corrigir.
Implementar bom tratamento de erros e registro: No servidor, é importante capturar e lidar bem com erros. Isso significa registrar erros para análise e depuração posterior, e não mostrar dados sensíveis em mensagens de erro enviadas ao cliente.
Exemplo de envio de uma resposta HTTP em Node.js usando Express:
app.get('/data', (req, res) => {
try {
const data = getDataFromDatabase();
res.status(200).json(data);
} catch (error) {
console.error('Erro:', error);
res.status(500).json({ error: 'Erro Interno do Servidor' });
}
});
