是否存在一种更好的方式区分正向/反向WS中的事件与动作响应？

[VVsxmja]

刚刚发现在 WebSocket 中，动作响应和事件是通过同一个 ws 混在一起推送给应用端的，就想知道怎么判断哪些消息是事件，哪些是动作响应。

跑去看了半天动作响应与事件的文档，感觉似乎只能通过收到的对象所拥有的字段来判断收到的消息究竟属于动作响应还是事件……

参考了一下各种 OneBot SDK 的实现，发现确实大家都在用类似的方法来判断

• koishi 是通过判断是否存在 post_type 字段来判断消息类型的
• Onebot.Net 是通过 echo 字段来判断的
• NoneBot 似乎也是通过 echo 字段来判断的

总感觉这种判断方式不是很好……

如果 OneBot 应用端能够选择发起一个 ws 连接专门用于接收事件推送，在需要执行动作的时候再创建新的 ws ，这样两边的消息就不会混在一起了🤔

或者增加一个共有的字段用来标记消息属于事件还是动作响应🤔

[ExerciseBook]

你是出于什么考虑想这样子区分的？

不过从可用性角度来说，少一个连接，可用性保证可以少很多事。

[VVsxmja]

标准里只规定了事件/动作响应对象有什么，而不是什么样的对象是事件/动作响应，我觉得这样不太严谨……

[ExerciseBook]

标准里只规定了事件/动作响应对象有什么，而不是什么样的对象是事件/动作响应，我觉得这样不太严谨……

我还是没太明白，给点例子。

[stdrc]

@ExerciseBook 他的意思是用一个统一的格式来表示 ws 连接上的 payload，比如：

{
    "type": "event",
    "payload": {
        "type": "message",
        "message": [...]
    }
}

{
    "type": "action_response",
    "payload": {
        "echo": 123,
        "retcode": 0,
        "data": {
            "user_id": ...,
            ...
        }
    }
}

[VVsxmja]

如果 OneBot 应用端能够选择发起一个 ws 连接专门用于接收事件推送，在需要执行动作的时候再创建新的 ws ，这样两边的消息就不会混在一起了thinking

或者增加一个共有的字段用来标记消息属于事件还是动作响应thinking

这两个是我拍脑袋随便想的……

[ExerciseBook]

ws 监听事件，http 响应事件？

[VVsxmja]

按照现有的标准似乎确实只能这么实现，就是应用端写起来稍微累一点……而且我想了一下，如果要追求性能的话，确实还是现有的方案（单个ws连接，用字段区分对象）比较好。

[stdrc]

你说的很对，不过因为通过是否存在某字段来区分事件和动作响应已经工作得挺好了（在曾经的 CQHTTP 和后来的 OB11 中），所以没有太大必要去做修改，破坏现有代码逻辑

[abrahum]

统一 payload 模型确实是个不错的想法，可以作为 ob13（如果还会有的话）的 feature

[crazywhalecc]

这里会存在很多争议的地方，我大概整理一下：

统一 payload（套一层）

这样的样子就像是上面说的：

{
    "type": "action_response", // 或 "event" 或 "action"
    "payload": {
        "echo": 123,
        "retcode": 0,
        "data": {
            "user_id": ...,
            ...
        }
    }
}

这种的优点在于能根据 type 区分是响应包还是事件包，从而无脑拿 payload。缺点也十分明显，首先对目前的结构变动过大，将内部的参数下放到了第二级别，在 OneBot 实现端、SDK 端处理上，尤其是基于对象狂魔语言，可能又要多很多套娃对象了，鉴于目前 OneBot 12 基本成型，可能此方案不适合在现阶段改动。

另加字段

这是我个人之前的设想，也有人和我提到过，就是加一个独立的字段：

{
    "type": "message",
    "message": [...],
    "payload": "event" // 或 "action_response" 或 "action"
}

这样的好处就是不用动基本的结构，只需要加一个判断的字段就够了。缺点就是还是需要现行修改下结构体对象，涉及的改动也不小，对于解释型语言或者弱类型语言好处理一些。现在的逻辑层面其实可以通过判断是否存在 retcode、detail_type 字段，添加额外的字段属于冗余设计，有利有弊吧。

关于楼主提到的问题

如果 OneBot 应用端能够选择发起一个 ws 连接专门用于接收事件推送，在需要执行动作的时候再创建新的 ws ，这样两边的消息就不会混在一起了🤔

我个人的意见是，如果需要在执行动作时再创建新的 ws，那就失去了 ws 全双工的意义了。当然如果你是为了做收发区分，你也可以在实现端让它发起两个反向 ws 或开一个正向 ws，你用 SDK 端发起两个连接，其中一个连接收到的事件完全忽略就可以做到了。

总感觉这种判断方式不是很好……

HTTP 协议的请求 payload 和 响应 payload 你也只能通过第一行的 HTTP/1.1 在哪个位置进行判断，所以我觉得判断关键字段存不存在而区分收发包并没有什么特别明显的不妥。

[ExerciseBook]

我也是感觉这样就失去了 ws 原本设计的想法了。

[stdrc]

其实这个问题主要是，以前 cqhttp 的时候是先有 event 和 action 分连接，之后才有 universal 连接的，后来 onebot 12 只保留了 universal 连接