Os cabeçalhos do protocolo HTTP contêm informações de metadados como, por exemplo, de autenticação de segurança, agente do usuário usado, controle de cache, entre outros. Esses cabeçalhos permitem que o cliente e o servidor passem informações adicionais com a solicitação ou a resposta HTTP. Em uma API REST, os tokens JWT (JSON Web Token) são incluídos no cabeçalho
- A)Authorization.
Correta, porque o token JWT é normalmente enviado no cabeçalho Authorization, muitas vezes no esquema Bearer.
- B)Content-Type.
Errada, porque Content-Type indica o formato do conteúdo da mensagem, e não serve para transportar o token de autenticação.
- C)Cache-Control.
Errada, porque Cache-Control controla armazenamento em cache, não credenciais de acesso.
- D)User-Agent.
Errada, porque User-Agent identifica o cliente/navegador, e não autentica a requisição.
Gabarito: A
Em HTTP, os cabeçalhos servem para carregar informações extras na conversa entre cliente e servidor. Pense neles como os "detalhes da negociação": tipo de conteúdo, idioma, cache, autenticação e até dados do navegador. Em APIs REST, quando o cliente precisa provar quem é, ele normalmente envia o token JWT no cabeçalho de autorização. O ponto central aqui é que o JWT não vai no corpo da requisição nem em um cabeçalho genérico qualquer. Ele costuma ser enviado no header Authorization, geralmente no formato Bearer . Isso é o padrão mais usado para autenticação por token em APIs REST. Os demais cabeçalhos citados na questão têm outras funções. Content-Type informa o tipo do dado enviado ou recebido, Cache-Control trata de cache, e User-Agent identifica o cliente que fez a requisição. Ou seja, cada cabeçalho tem seu papel, e misturar isso costuma custar ponto na prova. Se quiser guardar uma regra prática: se a ideia é autenticar a requisição com JWT, pense em Authorization. É a "carteirinha de entrada" da chamada HTTP.