Já pesquisei muito sobre esse assunto, li vários artigos sobre esse cabeçalho, seu uso no Heroku e projetos baseados em Django.
No entanto, ainda está tudo confuso na minha cabeça.
Respostas:
Quando você está operando um serviço da Web que é acessado por clientes, pode ser difícil correlacionar solicitações (que um cliente pode ver) com logs do servidor (que o servidor pode ver).
A ideia do X-Request-ID é que um cliente pode criar algum ID aleatório e passá-lo para o servidor. O servidor então inclui esse ID em cada instrução de log que ele cria. Se um cliente receber um erro, ele pode incluir o ID em um relatório de bug, permitindo ao operador do servidor consultar as declarações de log correspondentes (sem ter que depender de carimbos de data / hora, IPs, etc.).
Como este ID é gerado (aleatoriamente) pelo cliente, ele não contém nenhuma informação sensível e, portanto, não deve violar a privacidade do usuário. Como um ID exclusivo é criado por solicitação, ele também não ajuda no rastreamento de usuários.
Objetivo: Idempotência
Com um ID que muda para cada solicitação, mas permanece o mesmo no caso de uma nova tentativa de uma solicitação, o receptor pode garantir que a solicitação não seja processada mais de uma vez.
Esta é uma citação de algum provedor de API:
Todas as solicitações POST, PUT e PATCH HTTP devem conter um cabeçalho X-Request-Id exclusivo que é usado para garantir o processamento idempotente de mensagens em caso de nova tentativa
Se você torná-lo uma string aleatória, única por solicitação , não infringirá sua privacidade, nem permitirá o rastreamento.
Se você quiser saber mais sobre o que a idempotência tem a oferecer, leia este artigo perspicaz .
NB Como Stefan Kögl comenta, este cabeçalho não é padronizado - daí o prefixo "X-" (obsoleto).
Sua internet está funcionando (como sempre), então você liga para Tellstra e fica esperando no telefone para sempre ... finalmente você desiste e bate o telefone em frustração. (Esta é uma chamada falhada. E há um registro disso nos registros de chamadas de Tellstra.)
"É isso, vou ligar para o Provedor de Justiça!"
Mas o Obmudsman tem milhares de registros de chamadas para examinar (todas as consultas que falharam em Tellstra). Se você disser que ligou para a Telstra e que sua ligação não teve sucesso, não será suficiente: como a Ouvidoria saberá, de todos os registros de ligações de Tellstra, qual era a sua - para que possa ser investigada? ?
É aí que entra o X-Request-ID - sempre que você liga para a Tellstra, você passa um número aleatório (o X-Request-ID) e isso é registrado nos registros da Tellstra. Dessa forma, a ouvidoria (tendo acesso a todos os registros) poderá localizar sua ligação para saber o que deu errado.
O mesmo se aplica a solicitações http - é um id usado para ajudá-lo (como o desenvolvedor de back-end) a descobrir o que deu errado quando um cliente lhe envia um erro ou um grande relatório.
Esse é o resumo básico disso. Qualquer dúvida, etc., basta postar um comentário e espero esclarecê-lo.
Este cabeçalho de solicitação pode ser usado para sincronização. Digamos que você construiu uma lista de tarefas pendentes que oferece capacidade offline. Seu usuário cria 3 itens e cada um deles recebe um UUID exclusivo no aplicativo offline. Quando a conectividade de rede está disponível, os registros são postados no servidor e os IDs correspondentes gerados automaticamente a partir do banco de dados são retornados. Você pode então substituir os IDs em seu aplicativo (por exemplo, atributo "id" do elemento HTML "li").