Já sabemos que o HTTP é a base da comunicação na web e como as mensagens são formatadas e transmitidas entre clientes e servidores, sabemos também como os servidores devem responder a essas solicitações, vimos o que é o protocolo HTTP e seus fundamentos. Confira em Protocolo HTTP (Parte 1) - Introdução
Nesta parte do artigo vamos entrar em detalhes sobre métodos HTTP e seu funcionamento, com exemplos de uso. Além disso, também vamos conhecer alguns dos mais utilizados cabeçalhos(headers), tanto de requisição quanto de resposta. Bora lá?
1. Métodos HTTP
Um método é uma ação definida no protocolo, usada para indicar a intenção do cliente ao realizar uma solicitação a um servidor web. Esses métodos especificam o tipo de operação que o cliente deseja executar sobre um recurso identificado por uma URL. Em uma requisição HTTP, o método define a natureza da interação com o servidor, como: recuperar, criar, atualizar ou deletar dados.
1.1 GET
O método GET é comumente utilizado em solicitações HTTP. Ele solicita a recuperação de dados de um servidor sem modificar o estado do recurso no servidor.
Utilizado para recuperar informações de um servidor. Por exemplo, quando um usuário acessa a lista de pedidos realizados em um site de e-commerce, uma requisição do tipo GET pode ser enviada ao servidor para buscar os dados dos seus pedidos mais recentes.
Características:
- Seguro: Não deve alterar os dados no servidor.
- Idempotente: Múltiplas requisições GET têm o mesmo efeito que uma única requisição.
- Cacheável: A resposta pode ser armazenada em cache para otimizar a performance.
No exemplo abaixo, o cliente solicita uma lista de usuários.
1.2 POST
O método POST é usado para enviar dados ao servidor, geralmente resultando na criação de um novo recurso ou até a modificação de um recurso (apesar da existência dos métodos PUT e PATCH para isso).
Utilizado para criar informações em um servidor. Por exemplo, ainda em um e-commerce, no momento em que um usuário cria uma nova conta, uma requisição POST pode ser enviada ao servidor para criar o recurso.
Características:
- Não idempotente: Enviar a mesma solicitação POST várias vezes pode resultar em ações diferentes (como a criação de vários recursos).
- Usado para criar: Normalmente, usado para criar novos recursos no servidor.
No exemplo abaixo, o cliente está criando um novo usuário enviando os dados no corpo da requisição.
1.3 PUT
O método PUT é usado para substituir ou criar um recurso no servidor. Ele envia os dados completos do recurso para substituir o existente ou criar um novo se ainda não existir.
Utilizado para substituir ou criar informações em um servidor. Por exemplo, em um e-commerce, no momento em que um usuário vai avaliar uma entrega, uma requisição PUT pode ser enviada ao servidor para substituir ou criar o recurso.
Características:
- Idempotente: Múltiplas solicitações PUT têm o mesmo efeito que uma única, desde que o mesmo conteúdo seja enviado.
- Usado para substituir: Se o recurso já existir, ele é substituído; se não, ele é criado.
O exemplo abaixo substitui ou cria os dados de um usuário existente com ID 1.
1.4 PATCH
O método PATCH é usado para aplicar modificações parciais a um recurso. Ao contrário do PUT, que substitui completamente o recurso, o PATCH altera apenas os campos especificados.
Utilizado para modificar parcialmente informações em um servidor. Por exemplo, em um e-commerce, no momento em que um usuário altera o seu telefone na tela de perfil, uma requisição PATCH pode ser enviada ao servidor para modificar parcialmente os dados de perfil.
Características:
- Idempotente: Se o mesmo PATCH for aplicado várias vezes, o resultado será o mesmo.
- Modificação parcial: Usado para atualizar parcialmente um recurso existente.
O exemplo abaixo modifica o e-mail do usuário com ID sem alterar outros campos.
5.1 DELETE
O método DELETE é utilizado quando desejamos remover um recurso do servidor.
Utilizado quando desejamos remover informações em um servidor. Por exemplo, em um e-commerce, no momento em que o usuário decide excluir sua imagem de perfil, uma requisição DELETE pode ser enviada ao servidor para remover o recurso.
Características:
- Idempotente: Após a exclusão de um recurso, repetir a solicitação DELETE não terá mais efeito.
- Exclusão de recursos: Remove permanentemente o recurso especificado.
O exemplo abaixo remove o usuário com ID 1 do servidor.
1.6 HEAD
O método HEAD é semelhante ao GET, mas não retorna o corpo da resposta. Ele apenas recupera os cabeçalhos HTTP, o que é útil para verificar informações sem baixar o recurso completo.
Utilizado para consultar os cabeçalho de um recurso no servidor. Por exemplo, em um e-commerce, no momento em que acessa a página de um produto, uma requisição HEAD pode ser enviada ao servidor para consultar a data da última modificação do recurso e devolver um recurso de cache caso não tenha sido modificado desde a última consulta, evitando assim, requisições desnecessárias ao servidor.
Características:
- Seguro e idempotente: Assim como o GET.
- Sem corpo de resposta: Apenas cabeçalhos são retornados.
O exemplo abaixo verifica os cabeçalhos de resposta do recurso de usuário com ID 1, sem buscar o corpo da resposta.
1.7 OPTIONS
O método OPTIONS solicita informações sobre as opções de comunicação permitidas para o recurso no servidor. Ele informa quais métodos HTTP são suportados pelo servidor para o recurso em questão, políticas de CORS, entre outros.
Utilizado para solicitar informações em um servidor. Por exemplo, em um e-commerce, no momento em que um usuário efetua um pagamento, uma requisição OPTIONS pode ser enviada ao servidor externo de pagamento para confirmar se a origem da requisição é aceita pelo servidor externo, para somente depois enviar um POST em seu próprio servidor para finalizar a compra e efetuar o pagamento de fato.
Características:
- Descobre métodos permitidos: Útil para verificar quais operações podem ser executadas em um recurso.
- Idempotente e seguro.
No exemplo abaixo o cliente pergunta ao servidor as opções de comunicação no endpoint /api/users.
1.8 TRACE
O método TRACE é usado para fins de diagnóstico. Ele ecoa de volta a solicitação recebida pelo servidor, permitindo que o cliente veja o que foi enviado pelo caminho da solicitação.
Utilizado para diagnosticar o envio de solicitações pelo cliente. Por exemplo, afim de rastrear se um solicitação está sofrendo modificações(via proxies, firewalls ou gateways por exemplo) no meio do caminho até o servidor, uma requisição TRACE pode ser enviada ao servidor.
Obs. É sempre bom ter cautela ao deixar habilitado esse método no servidor, pois ele pode servir informações a usuários mal intencionados.
Características:
- Diagnóstico: Usado para rastrear a solicitação.
- Sem alterações no servidor.
No exemplo abaixo o servidor reflete a solicitação do cliente para fins de diagnóstico.
1.9 CONNECT
O método CONNECT é usado para estabelecer um túnel de comunicação com o servidor, geralmente para conexões seguras via HTTPS.
Utilizado para criar tuneis de comunicação com o servidor. Por exemplo, um usuário acessando o site de e-commerce em um ambiente corporativo que exige que todo o tráfego passe por um proxy HTTP, Nesse caso, o navegador do usuário utiliza o método CONNECT para solicitar ao proxy a criação de um túnel seguro para o servidor.
Características:
- Usado para tunelamento: Principalmente utilizado para criar um túnel SSL (HTTPS) via proxies.
- Sem manipulação de recursos.
No exemplo abaixo o cliente está solicitando a criação de um túnel para o servidor em www.example.com através da porta 443 (HTTPS).
2. Cabeçalhos (Headers)
Os Headers são partes das mensagens HTTP que contêm informações sobre a requisição ou resposta. Eles são inseridos logo após a linha inicial (que contém o método e o caminho para requisições, ou o status para respostas) e antes do corpo da mensagem. Os cabeçalhos permitem que cliente e servidor troquem dados essenciais sobre a transação, como o tipo de conteúdo, permissões de cache, dados de autenticação, entre outros.
2.1 Cabeçalhos customizados (Custom Headers)
O protocolo HTTP tem como uma de suas premissas ser altamente flexível, e um ponto onde podemos notar isso é nos cabeçalhos, o protocolo permite a criação de cabeças customizados para que clientes e servidores possam definir cabeçalhos específicos para atender suas necessidades de comunicação.
Uma convenção informal entre desenvolvedor é utilizar o prefixo "X" para identificar cabeçalhos customizados. Por exemplo "X-Custom-Header".
Apesar de ser uma convenção bastante difundida, já foi desencorajada como prática de uso, como podemos observar em RFC 6648.
2.2 Cabeçalhos genréicos (General Headers)
Esses cabeçalhos podem ser usados em ambos os tipos de mensagens HTTP (requisição e resposta) e fornecem informações gerais sobre a mensagem. Eles não estão diretamente relacionados ao conteúdo da mensagem.
Date: Indica a data e hora em que a mensagem foi gerada. É usado tanto em requisições quanto em respostas.
Connection: Controla se a conexão deve ser mantida aberta após a conclusão da troca de mensagens. Pode indicar se a conexão deve ser "keep-alive" ou fechada.
Transfer-Encoding: Indica como o corpo da mensagem está codificado para transmissão. Comum em respostas que utilizam "chunked" encoding.
Via: Indica os servidores intermediários (proxies) que processaram a mensagem. Útil para rastrear a origem de uma mensagem.
Keep-Alive: Usado para especificar parâmetros de conexão persistente, como o tempo máximo que a conexão deve ser mantida aberta ou o número máximo de requisições que podem ser feitas por conexão.
Warning: Fornece informações adicionais sobre a mensagem que podem não estar diretamente relacionadas ao conteúdo, como mensagens de cache ou de validade.
Content-Length: Indica o tamanho do corpo da requisição em bytes. O servidor usa essa informação para entender quantos bytes receber.
Content-Type: Indica o tipo de mídia do corpo da requisição, informando ao servidor como interpretar os dados recebidos.
Cache-Control: instrui tanto o cliente quanto os proxies intermediários sobre as regras de cache para a requisição ou resposta. Ele ajuda a otimizar o desempenho, evitando requisições repetidas desnecessárias.
2.3 Cabeçalhos de requisição (Request Headers)
Os cabeçalhos de requisição determinam utilização exclusiva nas requisições HTTP, ou seja, não existindo em outros contextos, como no contexto dos cabeçalhos de resposta.
Accept: Especifica os tipos de mídia que o cliente está disposto a receber do servidor. O servidor pode usar essa informação para enviar a resposta no formato desejado.
Accept-Encoding: Indica os algoritmos de codificação que o cliente suporta para a resposta. É frequentemente usado para compressão de dados.
Host: Especifica o nome do host e a porta do recurso solicitado. É essencial para servidores que hospedam múltiplos domínios.Origin: Especifica a origem (domínio, protocolo e porta) da requisição. É usado principalmente em requisições CORS (Cross-Origin Resource Sharing).
Authorization: Usado para enviar credenciais que autentiquem o cliente ao servidor. O formato pode variar dependendo do esquema de autenticação.
User-Agent: Fornece informações sobre o cliente (como navegador ou aplicativo) que está fazendo a requisição. Pode incluir detalhes sobre o sistema operacional.
Referer: Indica a URL da página anterior que fez a requisição para a página atual. Útil para rastreamento de navegação.
Cookie: Envia cookies armazenados pelo cliente ao servidor, permitindo a manutenção de sessões ou outras informações de estado.
If-Modified-Since: Permite que o cliente verifique se um recurso foi modificado desde uma data específica. Se não houve modificação, o servidor pode retornar um código 304 (Not Modified).
If-None-Match: Usado para realizar verificações de cache. Permite que o servidor determine se o recurso foi modificado desde a última vez que foi acessado.
Range: Solicita uma parte específica de um recurso, útil para downloads de arquivos grandes ou streaming.
Accept-Language: Especifica os idiomas que o cliente prefere para a resposta. O servidor pode usar essa informação para fornecer conteúdo em um idioma apropriado.
X-Forwarded-For: Usado para identificar o endereço IP original do cliente que está se conectando a um servidor por meio de um proxy.
2.4 Cabeçalhos de resposta (Response Headers)
Os cabeçalhos de resposta determinam utilização exclusiva nas respostas HTTP, ou seja, não existindo em outros contextos, como no contexto dos cabeçalhos de requisição.
Location: Usado em respostas de redirecionamento (códigos de status 3xx) para indicar a URL para a qual o cliente deve ser redirecionado.
Last-Modified: Este cabeçalho indica a última data e hora em que o recurso foi modificado. É utilizado por clientes e servidores para otimizar as requisições, permitindo verificações de atualização.
Content-Encoding: Este cabeçalho indica qualquer codificação aplicada ao conteúdo, como compressão, para que o cliente saiba como decodificar o corpo da mensagem.
Expires: O cabeçalho Expires indica a data e hora após a qual a resposta não deve ser considerada válida. É um método de controle de cache, especialmente em HTTP/1.0.
Server: Fornece informações sobre o servidor que está lidando com a requisição. Pode incluir o nome do software do servidor.
Set-Cookie: Usado para enviar cookies do servidor para o cliente. O cliente armazena esses cookies e os envia de volta em requisições subsequentes.
Retry-After: Indica o tempo que o cliente deve esperar antes de tentar novamente uma requisição, usado principalmente em respostas com código de status 503 (Service Unavailable) ou 429 (Too Many Requests).
Vary: Informa ao cache que a resposta pode variar com base em certos cabeçalhos da requisição. Isso permite cachear respostas diferentes para diferentes valores de
WWW-Authenticate: Usado para solicitar autenticação do cliente, informando o tipo de autenticação necessário. Geralmente visto em respostas com código de status 401 (Unauthorized).
Allow: Especifica os métodos HTTP que o servidor permite para um determinado recurso. Usado frequentemente em respostas a requisições OPTIONS.
Content-Disposition: Indica se o conteúdo da resposta deve ser exibido inline no navegador ou baixado como um arquivo anexo, além de permitir definir o nome sugerido para o arquivo baixado.
Strict-Transport-Security (HSTS): Instrui os navegadores a interagir com o site apenas através de HTTPS e a recusar quaisquer tentativas de conexão via HTTP por um período especificado.
Access-Control-Allow-Origin: Especifica quais origens têm permissão para acessar o recurso em respostas a requisições CORS (Cross-Origin Resource Sharing).
Clear-Site-Data: Usado para instruir o navegador a limpar dados armazenados, como cookies, cache, ou armazenamento local, relacionados ao site.
X-Content-Type-Options: Usado para proteger o site contra ataques de tipo MIME. A configuração mais comum é nosniff.
X-Frame-Options: Usado para controlar se uma página pode ser exibida em um <frame> ou <iframe>, ajudando a prevenir ataques de clickjacking.
3. Conclusão
Nesta parte do artigo tivemos a oportunidade de abordar conceitos essenciais para utilização do protocolo. Os métodos HTTP devem ser de conhecimento natural para todo desenvolvedor de software, sabendo lidar e interagir com os métodos mais utilizados. Sendo importante também conhecer os cabeçalhos mais utilizados a fim de ter mais compreensão ao utilizar o protocolo. Na próxima parte do artigo vamos falar sobre os status de resposta (status code) e suas mensagens (status message). Fique ligado e acompanhe as próximas postagens.