我应该将请求上下文放置在路径中还是标头中？

Question

我在设计一个系统

• 充当代理，在用户及其会话的上下文中调用后端上的服务
• 管理多个<#>后端的用户会话

我将通过HTTP公开系统。

大多数请求都需要后端id、用户id和会话id参数，现在我可以将其建模为路径参数。

/:back-end-id/:user-id/:session-id/...

或作为headers (x-agrzes-back-end-id、x-agrzes-session-id、x-agrzes-user-id)

把这些参数放在哪里更好？

对于代理端点，我肯定不希望它们出现在正文或查询中，因为我希望将它们转发给后端。

API将在服务器与服务器之间使用。

会话的含义可能类似于OAuth授权。系统管理访问凭据的获取和更新，然后透明地允许使用这些凭据访问后端资源。

因此，示例exchange可能如下所示

• 为具有后端foo的用户bar建立会话bazz
• < OAuth exhacnge由系统管理和指导>
• 在用户A和他的会话foo上下文中调用后端bazz上的调用服务D22(如果会话成立且凭据有效，则有效)

会话标识符是由客户端选择的，因此，当需要所有三个会话标识符(会话id、用户id、会话id)来查找会话时，客户端不必存储生成的会话标识符，因此可能是无状态的。

Answer 1

URL应该识别资源。因此，这取决于请求的语义。

我不会走任何一条路，只有一条路在中间。在不知道确切的用例的情况下，我认为后端id和用户id是您请求的资源的属性，因此它们应该是资源标识符的一部分。

另一方面，会话id是一个边界条件，而不是资源的真正属性。它更像是请求的一种属性。会话可能更改，也可能不更改，但资源不会更改，它对会话是不变的。因此，我认为会话id不应该是资源标识符的一部分，而应该是一个头。

如果用户id不是资源的一部分，而是用于授权目的(不考虑这可能是一个非常糟糕的想法)，那么它在头中可能会更好，如果会话id由于任何原因被认为是资源的一部分，则反之亦然。

Answer 2

看起来，您正在尝试通过无状态协议发送有状态数据。目的地疼痛！

在大多数情况下，您都希望会话id是特定于用户和后端的。它还将由代理而不是客户端生成。

考虑到这一点，我将让客户端使用Open(userid, backendid? (possibly generated by proxy))请求启动会话，并将会话id作为cookie添加到应答中，同时将相关的userid和后端id存储在代理上。

然后，客户端可以发送会话id cookie及其后续请求，并让代理从其内部存储中提取匹配的userid和后端。