我已经在这个主题上搜索了很多，阅读了关于这个标题的各种文章，它在 Heroku 中的使用，以及基于 Django 的项目。
然而，我的脑子里还是一片混乱。
【问题讨论】：
标签： http http-headers
当您操作由客户端访问的网络服务时，可能很难将请求（客户端可以看到）与服务器日志（服务器可以看到）关联起来。
X-Request-ID 的想法是客户端可以创建一些随机 ID 并将其传递给服务器。然后，服务器在它创建的每个日志语句中都包含该 ID。如果客户端收到错误，它可以将 ID 包含在错误报告中，从而允许服务器操作员查找相应的日志语句（无需依赖时间戳、IP 等）。
由于此 ID 由客户端（随机）生成，它不包含任何敏感信息，因此不应侵犯用户的隐私。由于每个请求都会创建一个唯一 ID，因此它也无助于跟踪用户。
【讨论】：
目的：幂等性
由于每个请求的 ID 都会发生变化，但在请求重试时保持不变，接收方可以确保不会多次处理请求。
这是来自某个 API 提供商的引述：
所有 POST、PUT 和 PATCH HTTP 请求都应包含唯一的 X-Request-Id 标头，用于确保消息的幂等性 重试时的处理
如果您将其设为随机字符串，每个请求唯一，则不会侵犯您的隐私，也不会启用跟踪。
如果您想了解更多关于幂等性的信息，请阅读this insightful article。
注意作为 Stefan Kögl cmets，此标头未标准化 - 因此（已弃用）“X-”前缀。
【讨论】：
您的互联网正在播放（像往常一样），所以您打电话给 Tellstra 并且您一直在等待电话......最后您放弃并沮丧地摔倒了电话。 （这是一次失败的通话。Tellstra 的通话记录中有记录。）
“就是这样，我要打电话给监察员！”
但是 Obmudsman 有数千条通话记录需要处理（Tellstra 的所有失败查询）。如果你告诉他们你给 Telstra 打了电话，但你的电话不成功，那还不够：申诉专员如何从 Tellstra 的所有通话记录中知道哪一个是你的 - 这样一来可以进一步调查吗？？
这就是 X-Request-ID 的来源——当您调用 Tellstra 时，您会传递一个随机数（X-Request-ID），这会记录在 Tellstra 记录中。这样，监察员（有权访问所有记录）将能够找到您的来电以找出问题所在。
这同样适用于 http 请求 - 它是一个 id，用于帮助您（作为后端开发人员）在客户端向您发出错误或大报告时找出问题所在。
这就是它的基本摘要。如有任何问题等，请发表评论，我希望能解决它。
【讨论】：
此请求标头可用于同步。假设您已经构建了一个提供离线功能的 ToDo 列表。您的用户创建了 3 个项目，并且每个项目都在离线应用程序上被赋予了一个唯一的 UUID。当网络连接可用时，记录被 POST 到服务器，并返回从数据库自动生成的相应 ID。然后，您可以替换应用中的 ID（例如 HTML“li”元素的“id”属性）。
【讨论】：