拦截器传递JWT解码信息：http:RequestContext与http:Request选哪个更优？

在请求拦截器完成JWT验证与解码后，要把如下自定义JWT记录传递到资源端点（service.bal）：

public type JwtRecord record {|
    string email;
    string[] roles;
|}

优先选择**http:RequestContext**来传递，原因如下：

• 语义完全匹配：RequestContext的设计初衷就是在请求处理链路中传递请求上下文相关的自定义元数据，解码后的JWT用户信息属于请求的上下文数据（并非请求本身的业务负载），用它传递完全契合框架设计意图。而http:Request的核心职责是承载HTTP请求的原始内容（请求头、请求体、参数等），将自定义上下文数据塞进Request属于对其职责的越界使用，语义上不恰当。

• 隔离性更强，维护成本低：RequestContext中的自定义数据与请求原始数据完全隔离，不会和Request自身的字段（如headers、内置attributes）产生命名冲突。后续维护时，能清晰区分哪些是原始请求数据，哪些是处理过程中生成的上下文数据，避免混淆。如果用Request传递（比如往其attributes中添加数据），很容易和框架或其他扩展逻辑的属性键冲突，排查问题时会额外增加成本。

• 避免意外副作用：RequestContext的生命周期与单个请求处理周期完全绑定，请求处理完成后即被清理，不会有残留数据问题。而直接修改Request对象，虽然生命周期匹配，但Request是请求的核心载体，修改它可能会意外影响到其他依赖Request的逻辑（比如后续的日志拦截器、监控统计逻辑等）。

如果你的业务场景需要将JWT信息传递给下游服务（比如通过转发请求时携带），那可以考虑将信息放到Request的请求头中，但仅在当前服务的拦截器到资源端点之间传递的话，RequestContext是最优解。

内容的提问来源于stack exchange，提问作者Dimuthu Madushan