[已解决] 请教RainbowChat服务端C2S消息处理中的一些业务问题

在 RainbowChat # onTransferMessage4C2S 处理客户端向服务端发送的消息，逻辑中处理了包括在群聊在内以及

1. 添加好友请求消息
2. 同意加好友请求消息
3. 拒绝加好友请求消息

以上三个请求也都是通过长链接的方式进行处理，个人理解是否可以将整体项目分为长链接服务(消息推送)，短链接服务(各微服务)
的方式，以上三个请求呢迁移至短链接的服务，其中用户如果在线可以调用长连接服务进行通知。

改动后可能 onTransferMessage4C2S 只处理群聊和临时消息的转发逻辑。

希望请教一下群聊和添加好友相关逻辑都放到onTransferMessage4C2S 是如何考虑的，有哪些优势，如果改成后面这样的话是否可行，会有什么样的问题吗？

你的问题很好，问到点子上了。其实这3个指令的http短连接接口，在服务端已经有了，只是因为历史原因原先通过长连接处理的方式一直都很稳定可靠，就暂时没有改成用http短连接的方式（虽然这短连接的接口已经写好），因为我这边做产品稳定可靠一直是优先考虑，多一个改动就动一个可能导致bug的可能性，本来它就工作的很好，所有就没折腾了。如果你很介意，完全可以换成http的方式（把写好的这3个接口调用就好了，调用前，你记得读一下它的实现代码，确保可靠）。

你可以看一下http rest接口手册里的这3个接口，它就是你想要的：


提示：你可以看到每个接口都有编号，你想看它的服务端实现代码，直接拿接口 编号在服务端工程全局搜就能找到了（http rest手册的前面章节里也详细告诉你了要怎么去用这个接口编号，你一定看看）。

引用：JackJiang 发表于 2023-02-20 18:30
你的问题很好，问到点子上了。其实这3个指令的http短连接接口，在服务端已经有了，只是因为历史原因原先通 ...

您的回复解决了我的疑问，非常感谢

引用：1462793455 发表于 2023-02-22 10:12
您的回复解决了我的疑问，非常感谢

嗯