onebot
onebot copied to clipboard
botuniverse
将通信方式 webhook 改为可选
- 状态：草稿
- 相关 PR：无
摘要
实现端并非必须实现通信方式 webhook。
动机
实现端对应用端发送事件后，应用端返回动作请求。动作请求完成后，无法在同一个连接内发送动作响应。
具体描述
OneBot 实现必须完整实现 OneBotRPC 所规定的所有通信方式（HTTP Webhook 为可选）和数据协议。每种通信方式可以允许用户同时配置多个。
局限
替代方案
不返回动作响应
此提议我认为是合理的。从 LibOneBot 开发角度来看，通信方式应该是无关实现本身的，但是有时候又会考虑到实现协议有可能和 OneBot 通信协议本身重合或冲突。比如，在某些语言中，启动了一个 Server 后，无法再启动另一个 Server 监听，可能需要考虑共用一个 Server 然后使用分流方式处理数据。再比如，现在的微信公众平台如果不使用认证，仅可使用被动回复的 Webhook 类似的方式回复微信，而此处微信假定它为 OneBot 一种实现，那么就只能使用 Webhook 通信方式进行沟通。
而现在已知的是，微信公众平台的被动回复本身就是无动作状态的，微信平台的服务器只会区分两种情况，一种是服务器访问成功，回复了期望内的值（例如不用回复消息时返回一个 success 字符串，回复消息时回复对应合规的 XML 对象），以及非法的值（非法时它会尝试重新发起一次 HTTP 请求），直到达到重试上限（默认好像是 5 次）或重试次数之内成功一次。
所以我们假设，在使用 libob 库开发 OneBot 实现时，如果我们选择实现微信公众号聊天，那么默认只能选择让 libob 本身开启一个用于接收微信服务器 Webhook 前方的HTTP 服务器，由 libob 转换为 OneBot 12 格式后再发起一个 HTTP 客户端，之后再通过回包对其转换，此处的 WebHook 通信方式应该是必不可少，其他通信方式反而可能是不可用的状态。假设使用了反向 ws，那么发出 ws 数据包后，由于是全双工，无法确定什么时候的动作数据回包会发送，只能通过一个最大限度的等待，比如 2 秒内收到动作请求即转换响应为被动回复等。
通信协议此处应该描述准确一点，大致意思就是，如果使用某种通信方式，则必须按照 OneBotRPC 规定的对应通信方式进行编写，而不是必须每种通信协议都应该保证可使用。
此处的 WebHook 通信方式应该是必不可少，其他通信方式反而可能是不可用的状态。假设使用了反向 ws，那么发出 ws 数据包后，由于是全双工，无法确定什么时候的动作数据回包会发送，只能通过一个最大限度的等待，比如 2 秒内收到动作请求即转换响应为被动回复等。
其实我感觉，作为 LibOneBot 应该要实现所有通信方式，微信公众号这种的 OneBot 实现应该有一个最大等待时间，对应用端来讲仍然可以采取任何通信方式连接。其实这和原来 WebSocket 的使用逻辑是一样的，应用端发送 action request 之后，也是需要等待 response 至一个超时时间的。
其实我感觉，作为 LibOneBot 应该要实现所有通信方式，微信公众号这种的 OneBot 实现应该有一个最大等待时间，对应用端来讲仍然可以采取任何通信方式连接。其实这和原来 WebSocket 的使用逻辑是一样的，应用端发送 action request 之后，也是需要等待 response 至一个超时时间的。
但是对于一些语言或平台本身的限制来说，可能无法同一时间实现对应 LibOB 所有的通信方式。比如浏览器无法直接实现多 Server，比如部分语言只支持 HTTP 协议等情况。我们的目标固然是让 OneBot 和 LibOB 在越来越多的语言和平台上运行，所以通信方式理论上不应作为必须实现的门槛。
此外，对于此 RFC 本身提到的替代方案，我认为目前的 Webhook 默认行为应该就是这样的。
但是对于一些语言或平台本身的限制来说，可能无法同一时间实现对应 LibOB 所有的通信方式。比如浏览器无法直接实现多 Server，比如部分语言只支持 HTTP 协议等情况。我们的目标固然是让 OneBot 和 LibOB 在越来越多的语言和平台上运行，所以通信方式理论上不应作为必须实现的门槛。
我在想，可以把对 OneBot 实现的要求改为“除非语言或运行环境不允许，否则应实现所有的通信方式，当确实有客观限制时应实现尽可能多的通信方式”。因为我们确实希望实现要支持更多通信方式，不然应用端和实现端对不上的话，生态还是残，所以还是对实现要求高一点比较好。