JSON RPC 2.0：请求对象上的额外字段是否违反规范？
JSON RPC 2.0: Do Extra Fields on Request Objects Violate Specification?
我正在编写一个 JSON RPC 符合 js 库。规范是否允许客户端沿 params 字段向 Request 对象添加自定义字段（例如 headers）？
例如
{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "headers": { "original-client": 12 }, "id": 1}
规范 (https://www.jsonrpc.org/specification#request_object) 没有提及任何关于添加额外字段的内容。
如果我的图书馆确实添加了 header 字段，是否违反规范？
同样的问题。 （我想添加用户身份验证信息/消息签名...）
您是对的，Specification 没有提及任何关于附加字段的内容。所以legally-speaking，不禁止就是允许
另一方面，我在这里至少找到了一个参考实现：www.simple-is-better.org/rpc/jsonrpc.py，如果解码消息包含额外字段，它会抛出异常。此代码来自 JSON-RPC 2.0 规范的作者之一 Roland Köbler。
所以，YMMV。
- 如果您的库只是专有系统的内部构建块，请继续。
- 如果您需要与其他 JSON-RPC 实现交互，请测试每一个。
- 如果库是供 public 使用的，请不要使用。
编辑：我使用以下协议解决了这个问题：
- 在 "payload" 消息之前，使用方法
"rpc.secinfo" 发送 standard-compliant 通知。 （rpc. 前缀是 per-spec 为扩展保留的）
"params" 字段包含适用的任何元数据（例如用户名、签名）- 示例：
{"jsonrpc": "2.0", "method": "rpc.secinfo", "params": {"user":"root", "signature":"0xDEADBEEF"}}<DELIM><payload><DELIM>
- 如果 header 数据为空，则假装没有特殊方法（即行为与标准 json-rpc 完全相同）。
接收方可以像任何其他调用一样解码 header 消息，只需要将 header 应用（检查 sig，无论什么）到以下消息。
讨论：
- 允许在不触及负载的情况下构建框架
- 允许在不解码负载的情况下解码 header
- 允许按原样使用byte-payload，特别是允许加密+文字有效负载共存（但是加密有效负载会破坏JSON-RPC兼容性！）
- "Unaware"接收者：会无声或大声地把rpc.secinfo呼叫丢掉，但可以操作。缺少 ID 表示通知，即接收方不会根据 JSON-RPC 规范发回响应。
- "Unaware" 发件人：收到的消息有效，no-header 条消息。
请随意重用此协议，但请注明此 SO 答案。
我正在编写一个 JSON RPC 符合 js 库。规范是否允许客户端沿 params 字段向 Request 对象添加自定义字段（例如 headers）？
例如
{"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "headers": { "original-client": 12 }, "id": 1}
规范 (https://www.jsonrpc.org/specification#request_object) 没有提及任何关于添加额外字段的内容。
如果我的图书馆确实添加了 header 字段，是否违反规范？
同样的问题。 （我想添加用户身份验证信息/消息签名...）
您是对的，Specification 没有提及任何关于附加字段的内容。所以legally-speaking，不禁止就是允许
另一方面，我在这里至少找到了一个参考实现：www.simple-is-better.org/rpc/jsonrpc.py，如果解码消息包含额外字段，它会抛出异常。此代码来自 JSON-RPC 2.0 规范的作者之一 Roland Köbler。
所以，YMMV。
- 如果您的库只是专有系统的内部构建块，请继续。
- 如果您需要与其他 JSON-RPC 实现交互，请测试每一个。
- 如果库是供 public 使用的，请不要使用。
编辑：我使用以下协议解决了这个问题：
- 在 "payload" 消息之前，使用方法
"rpc.secinfo"发送 standard-compliant 通知。 （rpc.前缀是 per-spec 为扩展保留的） "params"字段包含适用的任何元数据（例如用户名、签名）- 示例：
{"jsonrpc": "2.0", "method": "rpc.secinfo", "params": {"user":"root", "signature":"0xDEADBEEF"}}<DELIM><payload><DELIM> - 如果 header 数据为空，则假装没有特殊方法（即行为与标准 json-rpc 完全相同）。
接收方可以像任何其他调用一样解码 header 消息，只需要将 header 应用（检查 sig，无论什么）到以下消息。
讨论：
- 允许在不触及负载的情况下构建框架
- 允许在不解码负载的情况下解码 header
- 允许按原样使用byte-payload，特别是允许加密+文字有效负载共存（但是加密有效负载会破坏JSON-RPC兼容性！）
- "Unaware"接收者：会无声或大声地把rpc.secinfo呼叫丢掉，但可以操作。缺少 ID 表示通知，即接收方不会根据 JSON-RPC 规范发回响应。
- "Unaware" 发件人：收到的消息有效，no-header 条消息。
请随意重用此协议，但请注明此 SO 答案。