ASP.NET Core中如何在HTTP请求中传递AccountId？

我正在开发一个基于ASP.NET Core的新系统，系统中发起请求的主体（个人或服务）是User，用户登录后生成的令牌用于后续请求的身份验证。

系统中还有代表法律实体的Account，分为个人账户、企业账户或关联账户。一个用户可以操作多个账户（比如同时为个人和公司下单），当用户拥有多账户时需要选择一个账户进行操作。

核心需求是：用户能在多个浏览器标签页中以不同账户操作，因此所有与特定账户关联的请求都必须传递accountId。

可选方案列表 #

1) JSON Web Token #

将accountId与userId一同加入JWT，每次切换账户都需要签发新的JWT。但JWT存储在Cookie或本地存储时会在所有标签页共享，无法满足多标签页不同账户操作的需求，因此该方案不适用。

2) 请求头 #

使用自定义请求头传递accountId，但存在自定义请求头可能被从请求中剥离的风险。

3) 查询参数 #

• 对于查询请求：用查询参数很自然，比如筛选指定accountId的订单集合
• 对于命令请求：技术上可行，但把额外数据放在查询参数而非请求体中，容易造成理解困惑

示例：
获取账户下所有订单：

GET https://example.com/api/orders?accountId={accountId}  

代表账户创建订单：

POST https://example.com/api/orders?accountId={accountId}

4) URI路径 #

通过URI层级体现账户与订单的归属关系，示例：
代表账户创建订单：

POST https://example.com/api/accounts/{accountId}/orders  

向订单添加商品：

POST https://example.com/api/orders/{orderId}/items  

获取账户下所有订单：

GET https://example.com/api/accounts/{accountId}/orders

该方案的优点是明确展示订单属于特定账户；添加商品时无需传递accountId，只需验证用户对订单的访问权限即可。同时如果用户需要查看所有授权账户的订单，api/orders也能正常工作。但缺点是无法让所有订单相关请求都统一使用orders集合。

5) 请求体 #

仅适用于命令请求，将accountId放在请求体中，这样可以用简洁的URI /orders处理POST、PUT、PATCH请求。需要注意的是，根据业务规则，订单创建后不能修改accountId，因此PATCH请求中要限制这一点。该方案不适用于GET请求。

6) POST/PUT/PATCH用请求体，GET用查询参数 #

• 命令请求（创建、更新资源）：将accountId放在请求体中，符合订单属性的定位
• 查询请求：用查询参数筛选，逻辑合理

目前我在方案4和6之间摇摆，更倾向于方案6——因为accountId是下单的法律实体，属于订单的属性，放在请求体中很自然；查询时用查询参数筛选也符合习惯。URI方案虽然可行，但我希望所有订单操作都统一使用orders集合。

补充疑问 #

对于GET请求，有两个选项：

GET https://example.com/api/orders?accountId={accountId}  

或

GET https://example.com/api/accounts/{accountId}/orders  

两者返回结果相同，第二个选项仅意味着存在https://example.com/api/accounts/{accountId}这个资源。想知道有没有判断标准来选择合适的选项？

对于POST请求，同样有两个选项：

POST https://example.com/api/orders – with accountId in the body 

或

POST https://example.com/api/accounts/{accountId}/orders  

考量和GET请求一致。

核心提问 #

• 是否有其他可选方案？
• 我是否忽略或误解了这些方案的问题？
• 是否有RFC、实用标准或实践案例支持或反对某个方案？
• 有没有常见的解决方案？

内容的提问来源于stack exchange，提问作者M. Koch