¶ Request Id
Request-Id或X-Request-Id，用来标识一个HTTP请求。重试同一个请求时，一般会使用不同的Request Id，以区分前后的两次不同的请求（尽管这两次请求的意图可能是一样的）。Request ID一般由客户端生成，一般使用足够长度的随机字符串或UUID。
也有系统会把Request Id当成Idempotent Key来使用，在服务器端用来做请求去重。但是这种做法，不但容易产生误解，而且也仅仅达成了API幂等性要求的一部分，并没有起到幂等性应当起的作用：让API的行为本身幂等，并让服务间的集成更加便捷与鲁棒。
¶ Idempotency-Key
Idempotency-Key是一种由客户端负责生成，由服务器端负责校验的，用于确保同一个用户请求，不会被重复处理两次，而产生额外副作用的机制。2020年12月，paypal起草了《The Idempotency HTTP Header Field》，对Idempotency-Key进行了系统化的描述与定义。并已经被不少公司接纳和采用。但是这个实现尚未形成标准，仅供参考。有关Idempotent Key的更多内容，请参考：幂等控制
无论具体实现如何，引入独立的字段来做幂等控制，与请求本身的ID区分出来，从未来的可扩展性上来讲，是更优的。而且，一个接口，如果声明自己需要RequestId和Idempotency-Key，那么也会引发初级使用者的深入思考，引导其正确地传递参数值，而不是无脑地传随机UUID。
¶ Correlation Id
在微服务构架体系下，一每个用户请求的处理，常常是由一组后端服务协同的结果。在这个过程，各个微服务之间，可能会有远大于一次的系统交互。
Correlation-Id可以用于把这些独立，但是相关的请求（及消息），以统一的方式关联起来而引入的概念。从而解决服务可见性及故障排查的问题。所以并不建议将CorrelationId放到业务请求体之中。
Correlation Id，在HTTP中并没有官方定义[1]，而在JMS中有相关定义。
¶ 业务Correlation Id
用于业务实体之间关联的ID，也被称为Correlation Id，但是具有业务属性，需要与上述用于请求关联的Correlation ID区分。
这个业务关联ID的命名并不没有业界的统一规范，有时还会被称为SourceId或ParentId。需要结合上下文，通过ID的使用方式，来仔细分辩ID的本质。不能单纯通过名字来推断其用途。