admin 管理员组文章数量: 1184232
2024年4月16日发(作者：eavesdropper)
基于RESTful的即时通信业务开放接口的设计与实现
摘要:本文将分析使用RESTful架构实现服务器端即时通信开放接口的优势，
并介绍如何使用RESTful构架设计及实现即时通信的开放接口。本文介绍的即时
通信开放接口所具有的主要功能有：1-1聊天，群组聊天，通知订阅。本文所涉
及到的技术包括：服务器端即时通信开放接口的业务逻辑的设计，数据库表的设
计，JAX-RS包的使用。
关键字： RESTful架构风格，即时通信，开放接口
一、基于RESTful的开放接口系统结构
即时通信是基于移动互联网的一项开放业务。其开放接口的三种构架有
CORBA（通用物件请求代理架构）、 SOAP（简单对象访问协议）、 REST（表
述性状态转移）。
RESTful风格充分利用了HTTP定义的四种常用操作：
GET,POST,DELETE,PUT，并且可以为即时通信中的各种资源（包括实体和服务）
定义唯一的URI，使得对这些资源的操作十分的方便。与其他两种架构/协议相
比，RESTful风格的开发复杂度更低，更易于扩展系统功能。综上所述，使用
RESTful的体系结构来开发即时通信服务器端的开放接口更为合适。即时通信业
务的系统流程图如图1所示，整个业务使用了B/S模型。若客户端希望使用即时
通信的功能，首先需要向通信服务器发出请求。通信服务器收到并分析客户端请
求，将客户端发来的消息表示成XML格式（消息体可以为空），将这些信息封
装到HTTP包中，根据客户端请求编写相应的URL作为HTTP包的目的地址，
最后将此HTTP包发送到聊天服务器。不同的URL对应了聊天服务器不同的接
口（服务），聊天服务器做出相应处理，期间可能需要查询或修改数据库。接口
主要功能有聊天信息的发送、群组聊天、通知订阅。
图1系统流程图
二、基于RESTful的IM开放接口的设计
（一）资源设计
1、资源概述：如图2描述了整个即时通信业务所用到的主要资源（服务也
是一种资源）。由根节点/chat/{userId}到由蓝色矩形表示的资源有唯一的一条路
径，该路径上的各字符串可组成一串URL地址，即该资源对应的URL地址。
图2 资源图
2、聊天接口的资源描述见表1
表1聊天接口资源描述
3、群组聊天接口的资源描述见表2
表2 群组聊天接口资源描述
4、通知订阅接口的资源描述见表3
当前即时通信业务有两个通知，NOTE_1及NOTE_2，这两个通知均与群组
聊天有关。
NOTE_1的功能是，当群的某一参与者正式加入该群或退出该群时，向该群
中其他参与者发送通知，告知该用户状态的改变。
NOTE_2的功能是，当某一用户上线或离线时，向其所在群的参与者发送通
知，告知该用户状态的改变。
表3 订阅接口资源描述
（二）业务流程设计
1、1-1聊天发送消息的流程
通信服务器流程：
向
localhost:8080/demo/services/chat/{userId}/oneToOne/{otherUserId}/messages
调用POST方法，发送的信息为APPLICATION/XML格式，内容为
信息内容
聊天服务器端流程：
图31-1聊天发送消息功能中聊天服务器端流程图
2、群组聊天
1）创建群
通信服务器端：
向localhost:8080/demo/services/chat/{userId}/group调用POST方法。
其中，userId是登录当前客户端的用户账号，也是新建的群的创建者。
发送的信息格式为APPLICATION/XML。
聊天服务器端：
图4创建群功能中聊天服务器端的流程图
2） 群的创建者添加群成员
通信服务器端：
向
localhost:8080/demo/services/chat/{userId}/group/{groupId}/participants
调用POST方法。
其中userId是groupId群的创建者，其他人无权执行此操作。
发送的信息的格式为APPLICATION/XML，内容类似于
participant1
userId1
false
participant2
userId2
false
省略若干participant的描述…
聊天服务器端：
图5 群的创建者添加群成员功能中聊天服务器端的流程图
3） 删除群成员
通信服务器端：向
localhost:8080/demo/services/chat/{userId}/group/{groupId}/participants/
{participantId}调用DELETE方法。其中，userId是群号为groupId的群的创建者，
participantId是某个群成员在群中的编号。聊天服务器端：
图6 删除群成员功能中聊天服务器端的流程图
4）查询群的某个成员的信息
通信服务器端：向
localhost:8080/demo/services/chat/{userId}/group/{groupId}/participants/{parti
cipantsId} 调用GET方法。
其中，userId是群号为groupId的群的成员（状态为INVITED或
CONNECTED）。participantId是同一个群当中的一个成员号。
聊天服务器端：
图7查询群的某个成员的信息功能中聊天服务器端的流程图
6、发送群聊信息
通信服务器端：
localhost:8080/demo/services/chat/{userId}/group/{groupId}/messages
调用POST方法。其中，userId是群号为groupId的群的成员。
聊天服务器端：
图8发送群聊信息功能中聊天服务器端的流程图
3、聊天通知
1）订阅某个聊天通知
通信服务器端：
向
localhost:8080/demo/services/chat/{userId}/subscriptions/{subscriptionId}
调用POST方法。其中，subscriptionId是合法的通知编号。
聊天服务器端：
图9 聊天通知功能中聊天服务器端的流程图
2）退订某个聊天通知
通信服务器端：
向
localhost:8080/demo/services/chat/{userId}/subscriptions/{subscriptionId}
调用DELETE方法。其中，subscriptionId是合法的通知编号。
聊天服务器端：
图10退订某个聊天通知功能中聊天服务器端的流程图
4、数据库设计
为实现群组聊天功能，数据库中显然应该有代表用户实体的表
USERSTATUS和代表群编号实体的表GROUPID，若按照范式进行设计，则应添
加代表用户实体和群实体之间关系的表USER_GROUPID，用以表示特定用户属
于哪些群。用户数及群数很大时，这个表的行数会很大。当查找某个群中所有成
员时，需要在这个大表中进行选择操作，再考虑到即时通信业务的使用量，可知
这个操作会频繁发生且开销很大的。出于效率的考虑，为每个群创建了表
GROUPSESSION_x，用以表示群号为x的群有哪些参与者。当需要对群号为x
的群成员进行操作时，只需在表GROUPSESSION_x中进行操作，效率较高。
图11是为即时通信聊天接口设计的数据库的ER图。
图11 数据库的ER图
以下描述了实现即时通信业务需要使用到的数据库的各表的定义。
表GROUPID仅有一列，存放当前被占用的所有群的编号。当进行创建群操
作时，可利用该表查出还未被占用的最小的群编号，用此编号作为新创建的群的
编号。
表GROUPSESSION_x（x是聊天群编号）存储了群号为x的聊天群的所有
参与者的信息，每个参与者的信息由一行来表示。见表4
表4 表GROUPSESSION_x的定义
表MESSAGES仅在1-1聊天时用到，它的每行表示一条信息，这条信息是
由用户号为SENDER的用户发给用户号为RECEIVER的用户的，且信息发送时，
用户号为RECEIVER的用户不在线，因此暂时将这条信息存于数据库中。见表
5
表5 表MESSAGES的定义
表USERSTATUS中存储了当前所有已注册的用户的用户号及该用户是否在
线的信息。当用户上线/下线时，聊天服务器需要对该用户在该表中的状态进行
相应改变。见表6
表6表USERSTATUS的定义
表NOTE_x（x是通知编号）中存储了所有的用户号及该用户是否订阅了通
知x的信息。当用户订阅/退订通知x时，聊天服务器需要对表NOTE_x中对应
该用户的SUBED字段做出相应改变。见表7
表7表NOTE_x的定义
四、基于RESTful的IM开放接口的实现
（一）、1-1聊天的实现
1、 对1-1聊天的初始化
聊天服务器启动时，会自动创建表MESSAGES。初始时，表MESSAGES
的截图如图12所示。
图 12 表MESSAGES的初始状态的截图
2、发送1-1聊天信息
模拟用户号为100的用户给用户号为400的用户发送信息，且用户号为400
的用户当前在线。
图 13 1-1聊天发送信息的请求
聊天服务器返回给通信服务器的信息如图13、14所示。注意消息体中status
字段的值为SENDING，根据该信息，通信服务器得知当前用户号为400的用户
在线，可以直接将此信息发送给用户号为400的用户。
若消息的接收方不在线，则聊天服务器返回给通信服务器的信息中的status
字段的值为SAVEDINDB，表示该信息已存入数据库，则通信服务器不必将该信
息立刻发送给接收方的客户端。
（二） 群组聊天的实现
1、对群组聊天的初始化
聊天服务器启动时，会自动创建表GROUPID及表CURRENTGROUPID。
初始时，两个表的截图均如图15所示。
图 15 表GROUPID及表CURRENTGROUPID的初始状态
2 创建群
模拟用户号为100的用户创建一个群，除他自己之外，群的初始参与者还有
姓名为BILL，用户号为200的用户。由通信服务器发送给聊天服务器的该请求
的内容如图16所示。
聊天服务器收到此请求之后，查找表GROUPID，选出当前没有被使用的最
小的群编号，作为新创建的群的编号。新的群创建完毕后，聊天服务器返回给通
信服务器的内容如图17所示。
图 17 群创建成功的信息
3、群的创建者为群添加新成员
只有群的创建者可以继续为该群添加参与者，这些新添加的参与者的初始状
态为INVITED。
假设用户号为100的用户为群号为0的群的创建者，他要继续为该群添加新
成员，则由通信服务器发送给聊天服务器的该请求的内容如图18所示。
图 18 群的创建者继续为群添加新成员的请求
4、发送群聊信息
假设群号为0的聊天群已经被创建，用户号为100的用户希望在该群中发送
信息，该用户发送群信息的请求如图19所示。
图 19 发送群信息
此功能未完全实现。当通信服务器的URL地址确定后，需要添加一个代码
段，功能为向通信服务器发送信息，信息体为chatMessage。除此之外，当前的
其余功能均已实现。
5、删除群中的某参与者
由于删除群中的某个参与者这一功能较为复杂，若用图片表示业务过程会占
用较多篇幅，因此改用以主要代码段的方式表示该功能的实现，相应的主要代码
段如图20所示。
假设用户号为100的用户为系统管理员，他需要创建一个新的通知表
NOTE_2，设置表SUBED属性的默认值为“NO”。由通信服务器发送给聊天服务
器的该请求如图21所示。
图 4-15 创建通知表
通知表创建完毕后，该表为空，需要为该表导入当前所有用户。管理员可以
再次发送另一个请求，完成此功能。由通信服务器发送给聊天服务器的该功能的
请求如图4-16所示。
图 21 为通知表导入用户
以上两操作进行完毕后，通知表NOTE_2的内容如图22所示。
图 22NOTE_2表的内容
2、订阅/退订某通知
由于订阅和退订两个操作在业务逻辑及实现上十分相似，在此仅呈现订阅通
知的实现。
首先，运营商需要制定某个通知，为该通知定义通知号，并在数据库中创建
相应的表NOTE_x（x为通知编号），用该表表示用户是否订阅了通知x。某一时
刻，NOTE_1的内容如图23所示。
假设用户号为100的用户需要订阅某通知1，他需要相应的请求。从通信服
务器发送到聊天服务器的过程中该请求的内容如图24所示。
用户号为100的用户成功订阅通知1后，表NOTE_1的内容的截图如图25
所示。
图 25 表NOTE_1内容的截图
3、发送通知
该功能未完全实现，当通信服务器的URL地址确定后，需要添加代码段，
功能为，向通信服务器发送信息，信息体为通知内容。除此之外，包括通知的接
受者的查找等功能均已实现。图26给出了发送通知1的代码段。
本文较为简洁地介绍了基于RESTful的IM开放接口的设计和实现。从资源、
业务流程、数据库等方面，对基于RESTful的IM开放接口进行了设计。给出了
调用实现后的接口的大多数功能的截图，或某些功能的重要代码段。
参考文献
[1] 昊斯特曼等. Java核心技术：卷1基础知识. 北京：机械工业出版社，
2008-6-1.
[2] Bill Burke. RESTful Java with JAX-RS. O’Reilly Media Inc，2009-11-1.
面向移动互联网的业务能力开放技术标准综述
[3] 胡尼亚,张鹏,刘晓靖,杨瑞. 面向移动互联网的业务能力开放技术标准综
述.信息通信技术, 2011年04期.
[4] 王建斌,胡小生,李康君,赵靓. REST风格和基于SOAP的Web Services的
比较与结合. 计算机应用与软件,2010年09期.
[5] 许卓明,栗明,董逸生.基于RPC和基于REST的Web服务交互模型比较分
析. 计算机工程, 2003年20期.
版权声明：本文标题：基于RESTful的即时通信业务开放接口的设计与实现 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/p/1713274461a627011.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论