CN105900391A - 使用restlike api进行实时通信 - Google Patents

Abstract

一种计算设备执行应用的客户端侧实例，其支持利用符合表征状态转移（RESTlike）设计原则的应用编程接口（API）与服务器计算设备进行双向的实时同步通信和实时异步通信。服务器计算设备上的事件构架被用来对针对服务器上被客户端计算设备所请求的资源的更新进行汇总，并且进一步被用来向客户端计算设备传送指示有哪些更新可用的元数据。实时敏感更新包括在该元数据中，并且客户端计算设备可以决定何时以及如何检索其它可用更新。异步操作在服务器计算设备上由可以对服务器计算设备上的其它资源进行修改并且使得有关操作状态的更新被发送至客户端计算设备的操作资源进行建模。

Description

使用RESTLIKE API进行实时通信

背景技术

计算机所实现的统一通信（UC）应用使得其用户能够利用多种不同的通信形态接收并传送实时通信。例如，除其它通信形态之外，示例性的UC应用可以被配置为支持即时消息传送、话音通信、电话会议、视频会议、话音邮件检索、日历同步和内容共享。

传统上，端点与安装于其上的UC应用的客户端侧实例的信令已经由诸如SIMPLE、SIP、H.323、XMPP、Jingle、Skinny等之类的专用、私有和标准协议（基于会话的、命令和控制，或者逐跳的）所支持（power）。这些协议中的每一种已经被微调以针对UC应用所支持的通信的相应方面；例如，第一协议可以被用于电话呼叫建立，第二协议可以被用于设置或订阅个人的存在，等等。该方法的结果是常规UC应用的客户端侧实例相对复杂，因为核心逻辑被推送至这样的客户端侧实例（在本文被称之为“客户端”）。因此，客户端有效地用作各种信令流的相应协调点—如果客户端不能支持某些协议，则其不会被用户认为是成熟的（full-fledged）UC应用。在示例中，常规的基于web的客户端支持即时消息传送和存在（presence），但是并不支持企业范围的话音和视频通信，并且因此可能不被用户认为是成熟的UC应用。

由于以上所描述的架构，有若干种与常规UC相关联的缺陷。首先，轻量级客户端的演进是困难的，因为远程过程调用协议的变化相对不灵活，因为这样的协议迫使在客户端以及服务器上所执行的相对应代码之间进行明确或隐含的耦合（紧密耦合）。因此，如果新的特征被添加至UC应用，则旧有的客户端可能变得无法操作。另外，常规方法与高度存储器占用空间（footprint）、通信量（chattiness）和高带宽使用相关联。采用来对UC应用中常规的基于web的客户端提供支持的远程过程协议（RPC）可以使得服务器侧代码（本文被称之为“服务器”）经常同步100%的客户端状态，即使在客户端的用户接口需要相对少量信息时也是如此。此外，这样的方法与标准/监控工具的缺失相关联，因为以上所提到的RPC采用超文本传输协议（HTTP）作为传输层，其中一个统一资源定位符（URL）表示服务—这导致了缺少标准工具对UC应用的健康进行监控。

发明内容

以下是在本文中更为详细描述的主题的简要发明内容。该发明内容不是旨在作为对权利要求范围的限制。

本文描述了关于总体上符合表征状态转移（REST）架构的应用编程接口（API）的各种技术。当被UC应用所采用时，这样的API为同步通信（例如，IP话音通信（VoIP）、视频会议、应用共享、数据合作......）提供支持。此外，UC应用还可以支持异步通信（例如，在线会议调度、存在，以及同步联系人和群组信息......）。此外，采用本文所描述的API的UC应用可以实时地（以数毫秒或更短的量级）促进异步和同步通信。

在一个示例性实施例中，这样的应用可以是统一通信（UC）应用。支持这样的应用的系统架构包括与服务器计算设备进行通信的客户端计算设备，其中该客户端计算设备执行应用的客户端侧实例（客户端）并且该服务器计算设备执行服务器侧代码（服务器）。客户端计算设备可以包括台式计算设备以及诸如移动电话、平板设备（板式设备）、平板电话、可穿戴设备等之类的便携式计算设备。依据本文所描述的多个方面，客户端之间和/或客户端与服务器之间的实时同步和异步通信可以通过采用符合REST架构的API（例如，RESTlike API）来完成。

该API是根据标识符和命令而被建模，其中该标识符表示资源并且该命令表示与资源进行交互的方法，诸如常规超文本传输协议（HTTP）方法。该UC应用可以使用诸如常规超媒体类型的各种有效载荷格式而利用该API传送数据。资源可以是或包括数据，诸如文档、图像、数据库条目等。在另一个示例中，资源可以是或包括计算机可执行代码，诸如服务、可执行线程等。此外，资源通常关于由其相应标识符所描述的特定概念。例如，“联系人”资源可以包括用户的联系人的列表，或者可以是从其它资源检索联系人列表的服务。每个资源是由相应的全局标识符所标识，诸如可以被客户端用来访问相应资源的统一资源定位符（URL）。资源还可以包括其它资源的全局标识符，从而指示链接关系。例如，“联系人”资源还可以包括“简档”资源的全局标识符，所述“简档”资源包括用户联系人的简档。在访问“联系人”资源并且定位用于“简档”资源的全局标识符之后，该客户端然后可以使用用于“简档”资源的全局标识符来检索联系人的简档。这样的链接关系可以允许客户端以类似于用户可以使用超链接在网页内导航的方式而在资源内导航。

因此，UC应用所采用的示例性API可以使用链接关系来表达该UC应用所支持的能力，其中链接关系的使用符合HATEOAS（超文本即应用状态引擎）原则。通过添加新的链接关系可以引入新的能力。

如以上所提到的，命令表示与资源进行交互的相应方法。示例性方法包括从资源检索数据，向资源添加数据，替换或添加资源，以及删除资源。通过将标识符与命令在请求中进行组合，客户端可以指示所期望被访问的资源以及所期望被执行的资源。例如，为了检索用户的联系人列表，客户端可以生成包括表示检索操作的命令以及表示“联系人”资源的标识符的请求。

然而，添加、修改或删除服务器所支持的资源可以是合期望的，并且因此对客户端进行更新可能是合期望的。因此，在示例中，客户端可以针对事件（例如，列出针对资源的更新）向服务器发送“挂起请求”，其中该挂起请求是服务器不需要立即回复的请求。例如，服务器可以进行等待直至发生了更新从而生成/传送回复，而不回复以没有针对客户端所使用的资源的新的更新是可用的。

附加地，服务器可以运用事件构架以便对服务器上的事件以及资源的更新进行汇总，并且确定这样的更新的通知如何以及何时被递送至客户端。服务器可以向客户端传送描述可用的更新的元数据，而不发送所有这样的更新，例如同步100%的状态，并且客户端可以请求所期望的更新。在示例性实施例中，服务器可以将类别指派给每个事件/更新，其中示例性类别包括实时敏感、高度紧急和低度紧急。

当更新为实时敏感时，服务器可以将该更新嵌入到被传送至客户端的元数据中，从而允许客户端在不必确定需要更新，向服务器进行请求并且等待接收更新的情况下接收到该实时敏感的更新由此减少了递送实时敏感更新的延时。高度紧急更新可以在元数据中进行指示，并且客户端可以选择何时从服务器请求递送这样的更新。更新可以被急切地（例如，相对快速地）、怠惰地（在方便时或者在检索更新的成本低于阈值时）被检索，或者更新可以被忽略。低度紧急更新可以被服务器进行汇总并保留直至已经过去了预定时间段（例如，直至挂起请求超期）或者直至低度紧急更新变为更高紧急。关于早期检索的请求，高度紧急更新的提供可以被延迟相对短的时间段（例如，以50 ms的量级）以允许高度紧急更新的汇总。

另外，应用可以并入异步操作，其中一个或多个端点和/或服务器无需同时进行操作。例如，在电子消息传送中，接收方对于发送消息的发送方而言无需是活动的。异步操作可以由客户端发起，诸如期望发送消息的发送方，或者由服务器诸如在该服务器期望递送针对在多个异步工作的客户端之间进行共享的文件的更新时所发起。由于异步操作的多个部分可以在不同位置发生（例如，在客户端或服务器），并且由于这样的部分可能在不同时间发生，所以资源可以在客户端的请求已经完成之后持续处于服务器上。在常规（例如，无状态的）REST架构中，持续的资源可能在后续请求中并不被提供给客户端。然而，通过运用RESTlike API，客户端通过请求执行这样的异步操作，可以使得服务器创建操作的资源，所述操作资源可以在仍然遵循HATEOAS原则的同时，保持客户端关于异步操作的进程得到更新。

上述发明内容给出了简化的概述以便提供对本文所描述的系统和/或方法的一些方面的基本理解。该发明内容并不是对本文所描述的系统和/或方法的广泛的概述。其不是旨在标识出关键/必要要素或者描绘这样的系统和/或方法的范围。其唯一目的是以简化形式给出一些概念以作为随后所给出的更为详细的说明书的序言。

附图说明

图1和2是相应示例性系统的功能框图，所述系统促进执行在也支持异步通信的同时，通过使用RESTlike API而支持双向的实时同步通信的应用。

图3是示例性系统的功能框图，所述系统促进执行通过使用RESTlike API而支持异步操作的应用。

图4-9是图示用于通过使用RESTlike API而进行双向的实时异步和同步通信的相应示例性方法的流程图。

图10是图示用于通过使用RESTlike API而进行异步操作的双向通信的示例性方法的流程图。

图11是示例性计算系统。

具体实施方式

现在参考附图对关于通过使用符合表征状态转移（REST）架构的API在计算设备之间进行实时通信的各种技术进行描述，其中同样的附图标记始终被用来指代同样的要素。在以下说明书中，出于示例的目的，阐述了多种具体细节以便提供对一个或多个方面的透彻理解。然而，显而易见的是，这样的（多个）方面可以在没有这些具体细节的情况下而被实践。在其它实例中，公知的结构和设备以框图形式被示出以便促进对一个或多个方面的描述。另外，所要理解的是，被描述为由某些系统组件所实施的功能可以由多个组件来执行。类似地，例如，一个组件可以被配置为执行被描述为由多个组件所实施的功能。

此外，术语“或”是旨在意指包含性的“或”而非排斥性的“或”。也就是说，除非另外指出或者从上下文所明确，否则短语“X采用A或B”是旨在意指任意的自然包含性的排列。也就是说，对于实例：X采用A、X采用B或者X采用A和B，短语“X采用A或B”在以上任意实例下都得以满足。此外，除非另外规定或从上下文明确是指代单数形式，否则本申请和所附权利要求中所使用的冠词“一”和“一个”通常可以被解释为意指“一个或多个”。

另外，如本文所使用的，术语“组件”和“系统”是旨在包含利用计算机可执行指令进行配置的计算机可读数据存储装置，当所述计算机可执行指令被处理器执行时，所述计算机可执行指令使得某些功能得以被执行。该计算机可执行指令可以包括例程、函数等。还要理解的是，组件或系统可以位于单个设备或者跨若干设备进行分布。另外，如本文所使用的，术语“示例性”旨在意指用作某物的说明或示例而并非旨在指示偏好。

现在参考图1，图示了促进计算设备之间实时的同步和异步通信的示例性系统100。系统100包括多个客户端计算设备102-104。客户端计算设备102-104可以包括台式计算设备、膝上计算设备、上网本、超级本、平板设备（板式设备）、平板电话、移动电话等。系统100进一步包括服务器计算设备106，其通过适当的相应网络连接与客户端计算设备102-104进行通信。附加地，可以在客户端计算设备102-104中的计算设备之间直接建立通信信道以促进在其之间的通信。

客户端计算设备102-104和服务器计算设备106被配置为通过在客户端计算设备102-104和服务器计算设备106之间分布的通信应用而支持在其之间的同步和异步实时通信。更具体地，第一计算设备102包括第一处理器模块108，其执行保存在第一存储器110中的指令。第一存储器110可以包括被称作第一客户端112的通信应用的第一客户端侧实例。类似地，第N计算设备104可以包括第N处理器模块114，其被配置为执行第N存储器116中的指令。第N存储器116包括被称作第N客户端118的通信应用的第N客户端侧实例。

虽然服务器计算设备106在图1中被描绘为单个设备，但是服务器计算设备106可以是多个服务器计算设备（例如，分布式服务器）并且可以是或包括一个或多个虚拟机。服务器计算设备106包括服务器处理器模块120，其被配置为执行服务器侧存储器122中的代码。例如，服务器侧存储器122可以包括通信应用的服务器侧代码，其中该服务器侧代码被配置为支持该通信应用的至少一种通信形态。该服务器侧代码在本文中指的是作服务器124。例如，服务器124可以支持客户端计算设备之间的即时消息传送，维护并且向客户端计算设备提供存在信息等。

在客户端计算设备102-104和服务器计算设备106之间进行分布的通信应用可以支持计算设备之间的实时异步通信和实时同步通信。实时异步通信是指在接收设备未知的时间或时间间隔向接收设备（例如，客户端计算设备102-104之一）传送数据。例如，异步通信可以是文件传输、电子消息（例如，电子邮件、即时消息......）、事件调度请求、存在指示、针对联系人列表或群组的更新等中的至少一种。同步通信是指发送方和接收方都彼此进行通信并且同步的时候，虽然在一些实例中同步可以是近似的。例如，同步通信可以包括视频流式传输、视频会议、话音通信、在计算设备之间共享应用、桌面共享等。

在一个示例性实施例中，在客户端计算设备102-104和服务器计算设备106之间分布的通信应用可以是支持多种通信形态的统一通信（UC）应用，所述通信形态包括以上所提到的同步和异步形态中的至少一种。在另一个示例中，该通信应用可以是支持即时消息传送、存在和群组的社交网络应用或者包括在所述社交网络应用之中。在又另一个示例中，这样的通信应用可以是支持即时消息传送、存在和话音通信的即时消息传送应用。还预见到其它类型的通信应用。

客户端112-118和服务器124可以使用RESTlike API实时地同步进行通信。为此，客户端112可以使得图形用户接口（GUI）得以被显示，其例如包括客户端112的用户的联系人、客户端112所接收的消息等。例如，服务器124可以访问用户的联系人列表、经由客户端112所发送和接收的消息以及其它数据，以便例如填充该用户接口。例如，当第一客户端计算设备102的用户尝试向联系人（例如，第N客户端计算设备104的用户）发送通信时，第一客户端112可以经由服务器124或经由服务器124所建立的信道与第N客户端118进行通信。除了对通信进行路由之外，服务器124还可以向第一客户端112发送诸如联系人可以进行实时通信之类的其它信息。

如将在本文中更为详细描述的，RESTlike API是根据标识符和命令而被建模，其中该标识符表示存储在服务器存储器122中的资源，并且该命令表示与资源进行交互的方法，诸如常规的超文本传输协议（HTTP）方法和超媒体类型。资源可以是或包括数据，诸如文档、图像等。此外，资源可以是或包括计算机可执行服务或其它计算机可执行指令。另外，资源可以是或包括数据和计算机可执行指令的组合。附加地，每种资源可以被指向由其标识符所描述的相应概念。例如，“联系人”资源可以包括用户的联系人的列表。每种资源由相应的全局标识符所标识，诸如可以被客户端用来访问相应资源的统一资源定位符（URL）。资源还可以包括另一种资源（或多种资源）的全局标识符，以便指示该资源和另一种资源之间的链接关系。例如，“联系人”资源还可以包括“简档”资源的全局标识符，其中该简档资源包括用户联系人的简档。在访问“联系人”资源（例如，从服务器124）并且在其中定位用于“简档”资源的全局标识符之后，第一客户端112然后可以使用用于“简档”资源的全局标识符来访问联系人的简档。这样的链接关系可以允许第一客户端112以类似于用户可以使用超级链接在网页内导航的方式而在资源内进行导航。以下阐述关于RESTlike API的另外的细节。

现在参考图2，图示了通过利用RESTlike API而促进实时同步和实时异步双向通信（例如，在客户端和服务器之间或者客户端和客户端之间）的示例性系统200。系统200包括通过利用RESTlike API与服务器124进行通信的第一客户端112。在可替换的实施例中，服务器124可以被第N客户端118替换，以便第一客户端112和第N客户端118彼此直接通信。如以上所提到的，RESTlike API使用标识符和命令进行建模。这样的标识符和命令可以是通用的，这是由于它们无论所正在执行的具体应用、与之通信的具体设备或者所进行的具体操作如何都可以被使用，并且因此在设备之间提供了通用的接口。

现在对与RESTlike API相对应的资源进行描述。如所示出的，服务器124可以包括或可以访问多种资源（例如，第一资源202至第M资源204）。资源的格式是任意的，因为资源可以被构造为数据库、文件等。标识符可以相应表示资源202-204，其中资源可以包括数据（诸如文档、图像、一个或多个数据库条目等）、计算机可执行代码等中的至少一种。每种资源是关于相应概念的（例如，其可以直接由用于资源的标识符进行描述）。例如，第一资源202可以是“联系人”资源，并且因此可以包括第一客户端计算设备102（其包括第一客户端112）的用户的联系人的列表。每种资源是由相应的全局标识符所标识，其中全局标识符可以是可以被第一客户端112用来访问对应于该全局标识符的服务器124上的资源的通用资源定位符（URL）。例如，用于第一资源202的全局标识符可以如下：

/messagingapp/user/contacts。

资源还可以包括（多个）其它资源的（多个）全局标识符，以便指示与（多个）其它资源的链接关系。例如，第一资源202可以包括用于第M资源204的全局标识符，其中第M资源204是“简档”资源并且包括“联系人”资源中所包括的联系人的简档。因此，例如，第一资源202可以包括将第一客户端112的用户的联系人（例如，“联系人1”）与第M资源204的全局标识符相联系的数据库条目，其中该第M资源包括联系人1的简档，如以下示例中所示：

联系人	简档
		联系人1	/messagingapp/contact1/profile

资源202-204可以包括各种不同类型的资源，其包括但并不局限于动态资源、操作资源、发送方资源、事件资源、能力资源、容器资源、操作工厂资源、动态容器资源，和/或将以上所提到的资源的多个方面进行组合的资源。动态资源是很可能经常变化或更新的资源，诸如联系人的存在指示符；操作资源表示异步操作；发送方资源被配置为针对动态和操作资源的群组报告更新；事件资源包括发送方所分组的更新的批次或列表；能力资源表示特定客户端的能力；容器资源包括其它类型的资源；操作工厂资源是可以主要被用来发起操作资源的资源；动态容器资源包括其它资源并且在资源被插入、修改或变化时生成事件。也要理解的是，资源可以包括或组合以上所提到的资源类型。例如，操作资源也可以用作发送方资源并发送更新。

现在描述（由命令所表示的）RESTlike API所支持的用于与资源进行交互的方法。RESTlike API所支持的示例性方法包括常规的超文本传输协议（HTTP）方法和超媒体类型。因此，更具体地，示例性方法包括用于从资源检索数据（例如，经由“GET”命令）的方法，用于向资源添加数据（例如，经由“POST”命令）的方法，用于替换或添加资源（例如，经由“PUT”命令）的方法，以及用于删除资源（例如，经由“DELETE”命令）的方法。第一客户端112可以生成包括标识符和命令的请求，由此标识合期望地被访问的资源以及要结合该资源所执行的方法。因此，第一客户端112包括请求器组件206，其被配置为通过向服务器124发送包括方法的标识（诸如用于从方法检索数据的方法）以及合期望地被访问的资源的全局标识符的标识的请求来访问资源202-204中的资源。

例如，为了从“联系人”资源检索联系人列表，请求器组件206可以给出如下请求：

GET/messagingapp/user/contacts

其中“GET”标识用于检索数据的方法，并且/messagingapp/user/contacts是标识第一资源202的全局标识符。因此，第一客户端112可以请求服务器124的第一资源202的内容，而不必在本地存储联系人列表。使用全局标识符和方法允许第一客户端112针对资源做出请求而并不必对于该资源如何存储在服务器计算设备106或者服务器124实现所请求的方法的方式具有任何了解。

响应于从第一客户端112接收到针对第一资源202的请求，服务器124可以将第一资源202传送至客户端112。在另一个示例中，服务器124可以基于第一资源202的内容生成数据分组，并且将这样的数据分组传送至第一客户端112。例如，这样的数据分组在与第一资源202自身相比时，大小可能较小。附加地，在与第一资源202的格式相比时，该数据分组可能是为更容易被第一客户端112所解析的格式。在另一个示例中，其中资源是服务或者包括可执行代码，该数据分组可以包括表示该服务或可执行代码的数据。附加地，该数据分组可以是对客户端而言是可识别的格式。

因此，服务器124可以基于第一资源202的内容生成并返回数据分组，而不返回在请求器组件206给出的请求中所标识的第一资源202，其中这样的数据分组可以是或包括文档、列表等，并且可以为诸如标记文件（例如，XML）或对象注释文件（例如，JSON）的结构化的文件格式。例如，服务器124可以基于资源生成的数据分组可以是诸如以下的、包括联系人列表的数据库的JSON表示：

第一客户端112进一步包括接收器组件208，其接收从服务器124传送至第一客户端112的数据，诸如第一资源202或者基于其的数据分组，所述数据分组可以存储在可以被第一客户端112所访问的高速缓存中。

在示例性实施例中，如以上所指示的，第一资源202包括第一客户端112的用户的联系人的列表，并且可以进一步包括第M资源204的全局标识符，其中第M资源204包括第一资源202的联系人列表中的联系人的简档。因此，响应于接收到第一资源202或与之相对应的数据分组，第一客户端112可以标识第M资源的全局标识符。然后，请求器组件206可以从服务器124（例如，使用“GET”命令和第M资源204的全局标识符）传送检索第M资源204（或者其中所包括的数据）的请求。有效地，然后，第一资源202经由链接关系而被链接至第M资源204。资源202-204之间的链接关系允许第一客户端112以类似于用户可以使用超级链接在网页内进行导航的方式而在资源内进行导航。

第一资源202（包括第一客户端112的用户的联系人列表）在服务器124接收到针对这样的第一资源202的请求之前可能并不存在。在这样的情况下，服务器124可以响应于接收到该请求而收集生成第一资源202所需的数据，并且随后可以将第一资源202（或者相对应的数据分组）传送至第一客户端112。然而，所要理解的是，第一客户端112并不需要了解所请求的资源如何/何时被生成，因为RESTlike API在第一客户端112和服务器124之间提供了通用接口。因此，第一客户端112和服务器124可以被认为是松散耦合，这是因为第一客户端112和服务器124并不需要具有由其他另一方所执行的组件或方法的具体知识。

第一客户端112和服务器124所采用的RESTlike API可以利用附加的功能（或减少的功能）促进对第一客户端112进行更新。例如，服务器124所提供的服务或信息可以以合所期望的方式被更新，并且将这样的更新提供至第一客户端112可能是更加合期望的。

例如，通信应用可以利用新的特征进行更新，所述特征为用户提供联系人的列表以及该联系人列表中的每位联系人的位置数据。因此，在该示例中包括第一客户端112的用户的联系人列表的第一资源202可以被修改以包括多个资源202-204中的第I资源（未示出）的全局标识符。第一客户端112可以忽略新的链接关系，并且因此第一服务器112针对第一资源202所给出的请求保持有效。因此，第一资源202可以在不影响第一客户端112的行为的情况下被修改。在特定示例中，第一资源202可以被修改为包括如下：

联系人	简档	位置数据
			联系人1	/messagingapp/contact1/profile.	/messagingapp/contact1/location.

服务器124可以基于第一资源202生成如下数据分组：

继续该示例，第M资源204由全局标识符/messagingapp/contact1/profile.html所标识，并且针对这样的第M资源204的请求保持有效。因此，在服务器124上的更新并不必影响到第一客户端112的行为。

同样，第一客户端112可以被更新以便考虑到针对资源的变化而并不影响服务器124的操作。例如，第一客户端112可以被更新来预期用于第I资源的全局标识符，而使得请求器组件206在客户端112解析第一资源202（或与之相对应的数据分组）时传送针对第I资源的请求。

检测这些类型的更新例如可以包括通过资源的全局标识符进行导航，基于该导航构建映射或图形，并且将该映射或图形与之前的映射或图像进行比较。第一客户端112可以通过第一资源202中、诸如第I资源和第M资源204的全局标识符之类的全局标识符进行导航，并且可以类似地通过第I和第M资源204所包括的任意全局标识符进行导航。这样的导航可以针对另外的全局标识符所标识的另外的资源进行重复。然后，通过这样的全局标识符，导航随后可以被形成映射或图形，并且该映射或图形可以与之前的映射或图形进行比较以便检测变化。

针对客户端112和/或服务器124的更新并不需要以特定顺序或在特定时间实现，因为RESTlike API在客户端和服务器之间具有高度的向前和向后兼容性。因此，分布式通信应用中的客户端和服务器所支持的功能可以独立演进，而并不会中断或者变得无法一起使用。这种类型的行为尤其适用于相对大型的分布式架构，其中不可能在所支持的功能每次有所变化时都对整个编程环境进行重新部署。

附加地，服务器124上的资源202-204可以被修改或变化。在一个示例中，第一客户端112可以从服务器124请求资源，并且服务器124可以在每次从第一客户端112接收到请求时生成相应的响应。然而，频繁的请求会对实时通信造成不利影响。因此，可以结合确定第一客户端112何时以及如何得到有关针对相应资源的更新的通知以及这样的更新何时以及如何从服务器124被递送至第一客户端112而使用事件构架。为此，第一客户端112可以包括更新请求器组件210，其被配置为向被配置为检索针对资源202-204中的一个或多个的可用更新的标识的服务器124传送请求。在示例中，服务器124可以包括或可以访问事件资源212，所述事件资源212被配置为使得服务器124标识针对更新所指派的类别并且将更新的标识（或更新自身）传送至第一客户端112。例如，可以被指派给更新的类别可以1）包括实时敏感；2）高优先级；或3）低优先级。如以下更为详细描述的，事件资源212可以使得服务器124将实时敏感更新立即传送至第一客户端112，可以使得服务器124立即向第一客户端112通知可用的高优先级更新，并且可以使得服务器124在以下任意时刻之一向第一客户端112通知可用的低优先级更新，1）标识到实时敏感更新；2）标识到高优先级更新；或者3）针对事件资源202的挂起请求过期（例如，30秒、45秒、60秒）。

使用挂起请求减少了第一客户端112和服务器124之间的通信中的通信量，因为从服务器124到第一客户端112的回复将较不频繁。更新请求器组件210可以被配置为周期性地或者在接收到针对挂起请求的回复时传送挂起请求（例如，使得针对事件资源212的至少一个请求在第一客户端112正在被执行时是始终活动的）。

如以上所提到的，服务器124可以向事件资源212中所标识的每个更新指派相应类别，其中类别包括实时敏感、高度紧急或低度紧急。当事件资源212标识出被指派为实时敏感类别的更新时，服务器124可以立即针对来自第一客户端112的挂起请求生成回复，其中该更新被包括在回复之中。响应于第一客户端112的接收器组件208接收到该回复，更新请求器组件210可以向服务器124传送针对事件资源212的另一个挂起请求（例如，挂起GET）。因此，针对资源的实时敏感更新随着这样的更新在服务器124被标识而实时地在第一客户端112处被接收。附加地，响应于在事件资源212中标识出高度紧急更新，服务器124可以针对从第一客户端112所接收的挂起请求生成回复，其中该高度紧急更新针对第一客户端112在回复中被标识，但是该更新自身并不包括在回复之中。响应于接收到该高度紧急更新的标识，第一客户端112可以从服务器124请求更新（例如，其中该请求标识所要更新的资源）。针对被分类为低度紧急的更新，事件资源212可以对这样的更新进行汇总，其中服务器124在挂起请求过期时或者在低度紧急更新变为高度紧急更新时传送针对挂起请求的回复。服务器124所生成的该回复标识出可用更新，但是并不在回复中包括更新。

更具体地，如以上所指示的，针对资源202-204中的一个或多个的可用更新（例如，低度紧急更新）可以在事件资源212中进行汇总。因此，在资源202-204之一被更新时，服务器124使得关于这样的更新的信息被包括在事件资源212中。针对资源202-204的示例性更新包括向资源202-204添加资源，修改资源202-204中的资源中的数据（例如，相对于资源之前的状态），从资源202-204中删除资源，等等。因此，如果第一资源202被修改为包括针对第I资源的引用，则关于这样的修改的信息被包括在事件资源212中。

因此，事件资源212可以包括可被第一客户端112所使用的至少一个更新（或若干低度紧急更新）的标识。因此，事件资源212可以包括标识出可用更新的事件的列表、事件的相应更新类型，以及被更新的资源的相应全局标识符。事件资源212中所包括的示例性数据因此可以如下：

事件	所更新资源的ID	更新类型
			更新1	/messagingapp/user/contactslist	修改
下一个事件批次	/messagingapp/nextevents	新资源

当更新被归类为实时敏感时，第一客户端112尽可能快地（例如，实时地）接收到更新是合期望的。因此，当更新被服务器124归类为实时敏感时，该更新可以包括在服务器124在对针对事件资源212的挂起请求作出响应时传送至客户端112的回复之中——因此，该更新在服务器124识别更新时立即可被第一客户端112所使用。类似地，当事件资源212包括指示特定更新被归类为高度紧急的数据时，服务器124可以利用指示该更新可被客户端112使用的元数据对针对事件资源212的挂起请求进行回复（并不提供更新本身）。该回复例如可以通过VoIP套接字而被送至客户端112。

然而，被归类为低度紧急的更新并不需要立即被送至第一客户端112。相反，低度紧急更新的标识可以在阈值量的时间内在事件资源212中进行汇总，或者直至更新的紧急性发生被改变（例如，从低度紧急变为高度紧急）。这样的汇总可以有利地对第一客户端112和服务器124之间的通信有所影响。例如，如果另一个资源被添加并且然后被更新，则本是单独的两个更新可以被汇总在一起。由于另一个资源仅需要被请求并处理一次， 这不仅可以简化第一客户端112的处理，而且还可以减少应用的通信量，因为多个请求和/或更新被减少为针对汇总的更新的单次通信。

还可以意识到的是，高度紧急和低度紧急更新也可以被嵌入到针对挂起请求的回复之中。例如，更新的大小可能很小并且对于传送回复将不会有负面影响。在另一个示例中，可用更新的总数可能很低，而使得传送更新而不是等待请求是更为高效的。

来自服务器124的针对来自第一客户端112的挂起请求的回复可以包括元数据，该元数据包括更新类型的指示以及已经被更新的资源的全局标识符。可以在服务器对针对事件资源212的挂起请求进行回复并且更新并非实时敏感更新时，从服务器124向客户端112进行传送的XML文件形式的示例性元数据可以如下：

针对被归类为高度或低度紧急的更新，第一客户端112可以对来自服务器124的回复进行分析并且标识已经合期望地从服务器124检索的更新。然后，第一客户端112可以针对至少一个所期望的更新向服务器124传送请求。响应于该请求，服务器124将该更新提供至第一客户端112。

如以上所提到的，客户端112的接收器组件206从服务器124接收回复，响应于接收到该回复，第一客户端112向服务器124传送确认接收。在一些情况下，该确认还可以包括针对下一个批次的可用更新的挂起请求。由于该确认还包括下一个挂起请求，所以通信的通信量可以进一步被减少。由于从服务器124传送至第一客户端112的回复（除了包括被归类为实时敏感的回复之外）包括元数据但并不包括更新，所以第一客户端112可以确定何时以及如何检索更新，并且因此可以指引服务器124仅送出第一客户端112针对其准备接收和/或接收的那些更新。

第一客户端112还可以包括决策器组件214，其被配置为确定从服务器124所接收的回复中所标识的更新的检索类型。决策器组件214可以至少部分基于第一客户端112的能力、更新的紧急性或者网络流量条件中的至少一个来作出这样的决定。例如，第一客户端112可能每次仅正确接收一定数量的数据，并且因此无法接收所有可用更新；第一客户端112可能被设计为每次接收一定数量的更新；或者高网络流量可能导致通信延迟，这会影响到数据保真度或者以其它方式导致通信问题、瓶颈或错误。该检索类型可以是急迫检索、怠惰检索或不检索中的一个。

关于急迫检索，决策器组件214使得更新请求器组件210立即传送针对可被服务器124标识为对于服务器124而言是可用的更新的请求（例如，针对所更新的第一资源202的请求）。当检索类型为也被称作机会检索的怠惰检索时，决策器组件214在满足预定条件时使得更新请求器组件210传送针对可被服务器124标识为对服务器124而言是可用的更新的请求。该条件例如可以是当检索更新的成本低于阈值时；当没有其它更新或业务到来时，当第一客户端112和服务器124之间有某个通信速度或比特率可用时，等等。

决策器组件214还可以针对第一客户端112的当前状态和/或当前时间点确定从服务器124所接收的回复中所标识的更新并非是必要的，并且并不针对该更新做出请求（例如，检索类型为不检索）。然而，决策器组件214可以被配置为设置标志位以指示特定资源（例如，第一资源202）已经被更新，而使得当第一客户端112确定该资源被合期望地访问时，第一客户端112使得更新请求器组件210针对该资源的更新传送请求。响应于接收到针对更新的请求，服务器124向第一客户端112传送更新。

现在参考图3，图示了使用RESTlike API促进在第一客户端112和服务器124之间的实时双向通信期间执行异步操作的示例性系统300。系统300包括使用RESTlike API与服务器124进行实时通信的第一客户端112。

异步操作可以包括要由第一客户端112或服务器124中的至少一个所执行的至少一个步骤。例如，服务器124所执行的通过话音通信应用进行在被接受或拒绝之前可以指向多个客户端的呼叫的操作可以包括动作：1）接收从第一客户端112进行呼叫的请求；2）标识预期接收方；3）标识预期接收方的可用于接收呼叫的客户端；和4）完成呼叫请求。服务器124可以被配置为接收/生成该操作中的步骤已经被执行或者已经执行失败的指示。另外，该操作可以利用可以导致生成中间事件的框架进行建模。例如，为了第一客户端112理解呼叫的状态（例如，响铃、已连接或失败），事件合期望地被提供给第一客户端112，所述事件向第一客户端112指示操作的状态。

为此，第一客户端112包括请求器组件206，其中该请求器组件206向服务器124传送执行异步操作的请求。响应于接收到执行异步操作的请求，服务器124创建操作资源302。该操作资源302可以被用来对异步操作进行建模，并且可以在遵循开始、更新和完成的模式的专用瞬态资源之后进一步进行建模。

以上已经关于资源202-204而被描述的操作资源302可以使用命令进行访问并与之交互，上述命令包括诸如HTTP方法“GET”、“PUT”、“POST”和“DELETE”之类的方法。然而，操作资源302还可以被配置为使得服务器124添加（在该示例中）第一资源202、修改第一资源202或者删除第一资源202。这样的添加、修改或删除至少部分基于异步操作中的步骤。例如，在其中第一客户端112希望向第二客户端计算设备104的用户的联系人进行呼叫的示例中，该请求可以被传送至服务器124，所述服务器响应于接收到该请求而创建操作资源302。该操作资源302例如可以将第一资源202创建为“可用设备”资源，其包括指示该联系人的设备可以接收呼叫的数据。

操作资源302还被配置为使得服务器124传送事件，该事件表示异步操作的状态演进直至该异步操作最终成功或失败。随着异步操作朝向完成进行转变，操作资源302向事件资源212传送高度紧急更新/事件，并且如以上所描述的，服务器124可以传送标识针对第一客户端112的高优先级更新的回复。例如，当进行呼叫的请求已经被服务器124所接收时，该服务器可以使得高度紧急更新被送至第一客户端112以便指示该呼叫正在进行，并且检测到可用设备。操作资源302所标识的其它更新可以包括：操作开始；操作进行中；以及操作已经结束。这样的更新类型还可以包括有关操作状态的附加信息。在示例中，当更新类型为该操作已经结束时，该更新类型可以附加地包括该操作例如成功或者失败的信息以及该操作成功或失败的原因。

操作资源302还可以使得第一资源202被添加、修改或者从服务器124删除。服务器124可以使得这样针对第一资源202的更新被传送至事件资源212，并且像来自操作资源302的更新一样，该更新被归类为高度紧急。通过将有关异步操作的更新归类为高度紧急，如以上所描述的，有关该更新的元数据被立即传送至第一客户端112。因此，第一客户端112对异步操作的状态保持了解而并不必等待该异步操作完成。

如以上所描述的，客户端112进一步包括更新请求器组件210，其被配置为向服务器124发送针对事件资源212的挂起请求。在适当时，服务器124以上文中关于图2中的系统200的描述所给出的方式生成针对该挂起请求的回复。如以上所讨论的，该回复中的元数据可以指示第一资源202已经被更新。更新请求器组件210然后可以使用RESTlike API将针对第一资源202的更新的请求（例如，针对已经更新的第一资源202的请求）传送至服务器124。因此，当操作资源302已经使得第一资源202被添加、修改或删除时，第一客户端112被通知以这样的更新并且可以在期望时请求这样的更新。

响应于更新请求器组件210请求针对第一资源202的更新，服务器124可以传送这样的更新，并且第一客户端112的接收器组件208可以接收这样的更新（并且第一客户端112相应地被更新）。应当理解的是，当操作资源302使得诸如第一资源202的其它资源被更新时，这样的更新在异步操作完成之前被提供至客户端112，而无论该操作成功还是不成功地完成操作。通过这样做，针对资源的更新在与异步操作相关联的任何动态资源被删除之前被递送。

图4-10图示了与通过使用RESTlike API在计算设备之间进行双向的实时异步和同步通信相关的示例性方法。虽然该方法被示出并描述为按顺序执行的一系列动作，但是将要理解并意识到的是，该方法并不被该顺序的次序所限制。例如，一些动作可以以不同于本文所描述的次序发生。此外，动作可以与另一个动作同时发生。另外，在一些情况下，实现本文所描述的方法并非需要所有的动作。

此外，本文所描述的动作可以是可以由一个或多个处理器所实现和/或被存储在计算机可读介质或媒体上的计算机可执行指令。计算机可执行指令可以包括例程、子例程、程序、执行的线程和/或类似物。又另外地，方法中的动作的结果可以存储在计算机可读介质中，在显示设备上进行显示，等等。

现在参考图4，图示了通过使用RESTlike API而在计算设备之间促进双向的实时异步和同步通信的示例性方法400。方法400在402开始，并且在404，在客户端计算设备上执行应用的客户端侧实例，其中该应用支持通过使用RESTlike API而与第二计算设备的实时异步通信和实时同步通信。在406，客户端侧实例使用API实时地与服务器进行同步和/或异步通信。方法400在408结束。

现在参考图5，图示了在第一计算设备所执行的（使用RESTlike API）促进与第二计算设备实时地进行异步和同步通信的另一种示例性方法500。方法500在502开始，并且在504，针对服务器上的资源的请求被传送至服务器，其中该请求包括该资源的全局标识符。在506，从服务器接收有关该资源的数据，其中有关该资源的数据可以是XML文件、针对资源的更新等。方法500在508终止。

现在参考图6，图示了由第一（客户端）计算设备所执行的促进与第二计算设备（例如，服务器计算设备）实时地进行双向通信的另一种示例性方法600。方法600在602开始，并且在604，从客户端计算设备向第二计算设备传送包括全局标识符的挂起请求，该全局标识符标识服务器上的资源。在606，接收有关针对该资源的更新的元数据。该元数据可以标识可用于该资源的更新，或者可以包括针对该资源的更新。方法600在618完成。

现在参考图7，图示了由第一（客户端）计算设备所执行的利用RESTlike API促进与第二（服务器）计算设备双向地、同步地和异步地以及实时地通信的另一种示例性方法700。方法700在702开始，并且在704，包括资源的全局标识符的挂起请求被传送至第二计算设备，其中该全局标识符标识该资源。在706，从第一计算设备接收针对该挂起请求的回复，其中该回复包括标识针对该资源的可用更新的元数据。在708，确定用于检索该更新的检索类型，其中该检索类型可以是急迫检索、怠惰检索或不检索之一。在710，针对该更新的请求依据在710所确定的检索类型而被传送至第二计算设备。在712，从服务器接收该更新，并且方法700在714完成。

现在参考图8，图示了由第一（服务器）计算设备所执行的利用RESTlike API促进在第一计算设备与第二（客户端）计算设备之间进行双向的实时异步和同步通信的示例性方法800。方法800在802开始，并且在804，接收针对事件资源的挂起请求，其中该事件资源被保存在计算机可读存储介质中。在806，该服务器计算设备确定（事件资源以外的）资源已经被更新。在808，有关该资源的更新的数据被发送至事件资源，并且在810，该更新被归类为高度紧急。在812，服务器计算设备将针对该挂起请求的回复传送至客户端计算设备，该回复包括标识该更新可用的元数据。在814，在服务器计算设备在812传送回复之后，该服务器计算设备从客户端计算设备接收针对该更新的请求。在816，服务器计算设备将该更新传送至客户端计算设备，并且方法800在818完成。

现在参考图9，图示了在服务器计算设备执行的促进在服务器计算设备和客户端计算设备进行双向实时通信的另一种示例性方法900。方法900在902开始，并且在904，接收针对服务器计算设备上的资源的请求。例如，该请求可以包括该资源的全局标识符。在906，针对该请求的回复被传送至客户端，其中该回复包括与该资源相关的数据分组（例如，以可以由客户端计算设备进行解析的形式格式化的数据）。在908，从客户端计算设备接收挂起请求，该挂起请求标识被用来监控针对该资源所做出的更新的事件资源。在912，针对该挂起请求的回复被传送至客户端，其中该响应包括关于该资源的元数据。方法900在914完成。

现在参考图10，图示了在客户端计算设备执行的（例如，通过使用RESTlike API）促进执行与服务器计算设备的异步操作的示例性方法1000。方法1000在1002开始，并且在1004，执行异步操作的请求被传送至服务器。在示例中，该请求可以使得服务器针对所请求的异步操作创建操作资源。在1006，针对事件资源的挂起请求被传送至服务器计算设备。在1008，针对在服务器计算设备执行的操作资源中所表示的异步操作中的每个步骤，从服务器计算设备接收相应的高度紧急更新通知。在1010，从服务器计算设备接收标识针对另一个资源的可用更新的元数据。例如，该可用更新可以是由所执行操作的步骤所导致的更新。在1012，针对该更新的请求被传送至服务器计算设备，并且在1014，在客户端计算设备接收该更新。方法1000在1016完成。

现在参考图11，图示了可以依据本文所公开的系统和方法而使用的示例性计算设备1100的高层图示。例如，计算设备1100可以在使用RESTlike API而促进双向的实时异步和同步通信的系统中使用。作为另一个示例，计算设备1100可以在使用RESTlike API而促进执行异步操作的系统中使用。计算设备1100包括至少一个处理器1102，其执行存储在存储器1104中的指令。该指令例如可以是用于实现被描述为由以上所讨论的一个或多个组件所执行的功能的指令，或者用于实现以上所描述的一种或多种方法的指令。处理器1102可以利用系统总线1106访问存储器1104。除了存储可执行指令之外，存储器1104还可以存储应用实例、本地高速缓存、资源或资源的表示、更新、有关更新的元数据，或者更新通知或指示。

计算设备1100附加地包括数据仓库1108，其可以由处理器1102利用系统总线1106进行访问。数据仓库1108可以包括可执行指令、有关执行应用的客户端或者服务器的数据或元数据、资源、API指令或方法等。计算设备1100还包括输入接口1110，其允许外部设备与计算设备1100进行通信。例如，输入接口1100可以被用来从外部计算设备、从用户等接收指令。计算设备1100还包括输出接口1112，其将计算设备1100与一个或多个外部设备进行对接。例如，计算设备1100可以利用输出接口1112显示文本、图像等。

所预见到的是，经由输入接口1110和输出接口1112与计算设备1100进行通信的外部设备可以包括在提供用户可以与之进行交互的基本上任意类型的用户接口的环境之中。用户接口类型的示例包括图形用户接口、自然用户接口等。例如，图形用户接口可以接受用户采用诸如键盘、鼠标、遥控器等的（多种）输入设备所进行的输入，并且在诸如显示器之类的输出设备上提供输出。另外，自然用户接口可以使得用户能够以不受诸如键盘、鼠标、遥控器等的输入设备所施加的约束的方式与计算设备1100进行交互。相反，自然用户接口可以依赖于语音识别、触摸和输入笔识别、屏幕上和邻近屏幕的手势识别、悬浮手势、头部和眼睛追踪、话音和语音、视觉、触摸、手势、机器智能等。

附加地，虽然被图示为单个系统，但是要理解的是，计算设备1100可以是分布式系统。因此，例如，若干设备可以利用网络连接进行通信并且可以共同执行被描述为由计算设备1100所执行的任务。

本文所描述的各种功能可以以硬件、软件或者它们的任意组合来实现。如果以软件实现，该功能可以存储在计算机可读介质上或者作为计算机可读介质上的一个或多个指令或代码而被传送。计算机可读媒体包括计算机可读存储媒体。计算机可读存储媒体可以是能够由计算机进行访问的任意可用存储媒体。作为示例而非限制，这样的计算机可读存储媒体可以包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储装置、磁盘存储装置或者其它磁性存储设备，或者可以被用来承载或存储指令或数据结构形式的所期望的程序代码并且可以由计算机所访问的任意其它介质。如本文所使用的，盘或碟包括紧致盘（CD）、激光盘、光盘、数字多功能盘（DVD）、软盘和蓝光盘（BD），其中盘通常以磁性方式再现数据而碟在通常利用激光以光学方式再现数据。另外，所传播的信号并不包括在计算机可读存储媒体的范围之内。计算机可读媒体还包括通信媒体，所述通信媒体包括促进计算机程序从一处传输至另一处的任意介质。例如，连接可以是通信介质。例如，如果软件从网站、服务器或其它远程源使用同轴线缆、光纤线缆、双绞线、数字订户线路（DSL），或者诸如红外、无线电和微波之类的无线技术进行传送时，则该同轴线缆、光纤线缆、双绞线、DSL或者诸如红外、无线电和微波之类的无线技术包括在通信介质的定义之内。以上的组合也应当包括在计算机可读媒体的范围之内。

可替换地或附加地，本文所描述的功能至少部分可以由一个或多个硬件逻辑组件来执行。例如而并非限制，所能够使用的硬件逻辑组件说明性类型包括现场可编程门阵列（FPGA）、程序专用集成电路（ASIC）、程序专用标准产品（ASSP）、片上系统（SOC）、复杂可编程逻辑器件（CPLD）等。本文所描述的处理器模块和/或处理器模块与相关联存储器的组合是旨在包含这样的硬件逻辑组件的任何一种。

以上已经描述的内容包括一个或多个实施例的示例。当然，并不可能出于描述上述方面的目的而对以上设备和方法的每一种能够想到的修改和变更形式进行描述，但是本领域普通技术人员能够认识到，各个方面的许多进一步的修改和置换是可能的。因此，所描述的方面是旨在包含落入所附权利要求的精神和范围之内的所有这样的变更、修改和变例。此外，就在具体实施方式或权利要求中所使用的术语“包括”而言，这样的术语是旨在以类似于术语“包含”的方式而是包括性的,这是由于在“包含”被使用时，其在权利要求中被解释为过渡词。

Claims (10)

1. 一种计算设备，其包括：

处理器模块；和

存储器，其包括应用的客户端侧实例，该应用的客户端侧实例由该处理器模块所执行，该应用使用符合表征状态转移（REST）架构的应用编程接口（API）支持在该计算设备与第二计算设备之间的实时同步通信和实时异步通信。

2. 根据权利要求1所述的计算设备，该应用的客户端侧实例包括：

请求器组件，其使用该API向该第二计算设备传送请求，该请求包括资源的全局标识符；和

接收器组件，其从该第二计算设备接收基于该请求的回复，该回复包括该资源的表示、针对该资源的更新或者针对该资源的元数据中的至少一种。

3. 根据权利要求1所述的计算设备，该应用的该客户端侧实例进一步包括：

更新请求器组件，其向该第二计算设备传送针对事件资源的挂起请求，该事件资源包括与针对该第二计算设备所保存的资源的更新相关的数据，该挂起请求包括该事件资源的全局标识符；和

接收器组件，其接收针对该挂起请求的回复，该回复包括基于该事件资源中所包括的该数据的元数据，该元数据包括该更新的类型的指示以及该资源的全局标识符。

4. 根据权利要求3所述的计算设备，其中该回复无法包括该更新，并且该应用的该客户端侧实例进一步包括决策器组件，其至少部分基于该计算设备的能力、该更新的紧急性或者网络业务量条件中的至少一种来确定更新的检索类型，该决策器组件使得该更新请求器组件基于该检索类型而传送该挂起请求。

5. 根据权利要求3所述的计算设备，其中该更新的类型是在该第二计算设备上添加资源，修改该资源或者从该第二计算设备删除该资源之一。

6. 根据权利要求1所述的计算设备，该应用的该客户端侧实例进一步包括请求器组件，其使用该API向该第二计算设备传送执行异步操作的请求，其中该请求被配置为使得该第二计算设备在该第二计算设备上创建操作资源，该操作资源能够被用于基于该异步操作的至少一个步骤对该第二计算设备上的资源进行更新，该操作资源进一步能够用于使得该第二计算设备对该第二计算设备上的事件资源进行更新。

7. 根据权利要求1所述的计算设备，其中该实时异步通信是文件传输、电子消息、事件调度请求、存在指示、针对联系人列表的更新或者针对群组列表的更新中的至少一种。

8. 根据权利要求1所述的计算设备，其中实时同步通信包括视频流、视频会议、话音通信或有关应用共享的数据中的至少一种。

9. 一种由计算设备的处理器模块所执行的方法，该方法包括：

执行应用的客户端侧实例，其利用符合表征状态转移（REST）架构的应用编程接口（API）支持在该计算设备与第二计算设备之间的实时同步通信和实时异步通信；并且

利用该应用实时地异步和/或同步传送和接收数据。

10. 根据权利要求9所述的方法，其中利用该应用实时地异步和/或同步传送和接收数据包括：

利用该API向该第二计算设备传送针对资源的请求，该请求包括该资源的全局标识符；和

从该第二计算设备接收针对该请求的回复，该回复包括资源的表示、针对该资源的更新或者针对该资源的元数据中的至少一种。