面向RESTful系统的离线支持

18750面向RESTful系统的离线支持0托比亚斯∙费蒂格维尔茨堡-施韦因富特应用科学大学维尔茨堡 tobias.fertig@fhws.de0彼得∙布劳恩维尔茨堡-施韦因富特应用科学大学维尔茨堡 peter.braun@fhws.de0摘要0表述性状态转移（REST）是一种高效且已经被广泛应用的分布式超媒体系统的架构风格。然而，REST尚未设计用于离线操作，但许多应用程序在离线超过几秒钟时也必须保持功能。给程序员增加有关离线状态的知识是不可取的。RESTful应用程序可以通过一个形式化模型来描述。因此，我们定义了一个函数，用于推导客户端处理离线支持的代理的形式化模型。然后，我们扩展现有的缓存方法，以便客户端代理可以从应用程序中透明地隐藏离线状态。我们使用从模型中导出的所有测试用例来验证我们的解决方案。使用我们的模型和代理，客户端无需知道和担心自己是在线还是离线。0CCS概念0•软件及其工程→基于模型驱动的软件工程；客户端-服务器架构；分层系统；0关键词0REST，RESTful应用程序，RESTful系统，离线支持，超媒体，离线优先，MDSD0ACM参考格式：Tobias Fertig和PeterBraun。2018。面向RESTful系统的离线支持。在WWW '18Companion：2018年Web会议伴侣，2018年4月23日至27日，法国里昂。ACM，美国纽约，纽约，6页。https://doi.org/10.1145/3184558.319165501 引言0表述性状态转移（REST）是由Fielding在他的博士论文中引入的[2]。尽管REST很受欢迎，但许多开发人员忽略了REST的几个约束。这就是为什么Fielding的博客文章解释了RESTAPI必须是超文本驱动的，以满足超媒体约束[3]。这个约束要求稳定的互联网连接，以允许客户端与服务器不间断地通信。然而，任何地方任何时候都不可能有稳定的互联网连接。在客户端提供离线支持能否改善用户体验？我们遇到了几种可以从离线支持中受益的场景：0本文发表在知识共享署名4.0国际许可证（CC BY4.0）下。作者保留在个人和公司网站上传播作品的权利，并附上适当的归属。WWW '18Companion，2018年4月23日至27日，法国里昂，© 2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可证发布。ACM ISBN978-1-4503-5640-4/18/04。https://doi.org/10.1145/3184558.31916550坐在飞机上迫使人们在离线模式下工作。因此，任何不提供离线支持的应用程序都无法被乘客在飞机上使用。云计算也受益于离线支持。当前的浏览器使用离线存储来实现Web或云应用的离线工作。谷歌在其开发者文档中建议采用“离线优先”方法（https://developer.chrome.com/apps/offline_apps）。离线优先建议将应用程序编写为不需要互联网连接。一旦应用程序可以离线工作，可以添加网络功能。现在，开发人员必须手动实现离线支持，并且还被迫区分离线和在线模式。RESTful系统中的离线支持是否是个矛盾？是否有任何方法可以减少开发人员实现离线客户端的工作量？为了回答这些问题，我们对相关工作进行了一些研究，将在下一节中讨论。第三节提出了本文的研究问题，然后在接下来的第4、5和6节中回答这些问题。之后，我们将使用我们的模型及其实现展示结果。最后，我们将对未来的工作进行简短的展望。02 相关工作0Satyanarayanan提出了Coda，这是一个使用客户端-服务器模型运行的分布式文件系统[10]。它区分了少量可信的服务器和大量不可信的客户端。Coda使用基于回调的缓存一致性：服务器记住了客户端缓存的对象。然而，Fielding为REST定义了无状态约束：服务器必须是无状态的，以提高整个系统的可扩展性。因此，Satyanarayanan的方法不适用于RESTful系统[2]。Gonçalves和Leitão为Web应用程序的离线执行做出了很大贡献[5]。他们描述了一个包含服务器逻辑子集的离线模型。交互模型描述了本地服务器必须作为代理工作，如果在线的话必须转发所有请求。在离线模式下，代理必须保存离线请求并返回离线响应。如果客户端稍后上线，所有离线工作必须同步回服务器[6]。然而，Gonçalves和Leitão专注于填充离线缓存的预取机制，我们认为这是我们未来工作的一部分。断开连接的操作不仅适用于Web应用程序。事实上，分布式系统已经考虑到了它们。然而，这些考虑并不适用于Web架构。然而，一些分布式系统定义了类似的目标。例如，Demeers等人为他们的Bayou架构定义了以下目标：首先，离线方法必须支持资源有限的设备。其次，应确保读写操作的高可用性。第三，必须有一种机制来支持更新冲突的检测。最后，必须建立应用程序特定的解决更新冲突的方法[1]。0论文集：第九届Web API和服务架构国际研讨会 WWW 2018，2018年4月23日至27日，法国里昂Every ε-NFA can be described as a tuple (S, Σ,s0,δ, F), where Sis a finite, non-empty set of states. Σ is a finite, non-empty set ofsymbols representing the input alphabet. s0 ∈ S is the initial state ofthe ε-NFA. δ is the state transition function δ : S × (Σ ∪ ε) → P(S),where P(S) is the power set of S and F ⊆ S is the set of acceptingstates. Zuzak, Budiselic and Delac described three main parts of ε-NFA operations: the Input Symbol Generator, the Transition Functionand finally the Current State [13].They mapped a RESTful system to the ε-NFA formal model asfollows: Let Reqs be a finite set of valid requests, let Metas be afinite set of metadata key-value pairs, let LTypes be a finite set oflink types and let MTypes be a finite set of media types. Finally, let18760Hoodie（http://hood.ie）专为前端Web应用程序设计，并遵循离线优先的方法（http://offlinefirst.org）。Hoodie提供了一个本地的、用户特定的数据库，可以自动同步回服务器。Loopback（https://loopback.io）是一个Node.jsAPI框架，通过同构JavaScript实现离线同步。数据复制是基于模型的数据持久化实现的。该框架主要用于同步多个后端。因此，它的重点不是离线支持。此外，这些框架不专注于RESTful系统，它们需要特定的后端才能正常运行。这就是为什么我们试图定义一个通用模型，不仅可以为正在开发的RESTful系统添加离线支持，还可以为现有系统添加离线支持。03 研究问题0本节列出了必须在本工作中回答的三个研究问题，并描述了我们的研究方法：0Q1 RESTful系统和离线支持是否可以结合？Q2如何以层次化的方式组织离线支持的功能？Q3RESTful系统是否有通用的离线支持解决方案？问题Q1将在下一节通过文献研究来回答。然后，我们将提出一个六级层次结构来回答问题Q2（第5节）。问题Q3将通过使用一个形式化模型来描述RESTful系统来回答。04 离线支持和REST0为了回答Q1，我们回顾了有关将REST架构风格与离线操作相结合的现有方法的最新文献。Richardson [7]和Webber[12]根本不谈论离线支持，因为他们只关注如何设计和实现这样一个RESTful系统的服务器端。然而，Richardson至少写了一章关于缓存，但重点是HTTP[8]。与文献相反，搜索全球网络会导致不同的方法来实现RESTful系统的离线支持。由于无状态性和缓存的使用，REST本质上适用于许多离线场景。例如，安全请求（如GET）由于缓存可以很容易地在离线模式下支持。此外，幂等请求（如PUT）和DELETE可以很容易地在客户端上排队以供以后交付[4]。当然，将修改后的数据同步回服务器可能会导致严重的情况，这可能很难甚至不可能解决。然而，无论这些问题是在发出请求时还是在同步期间发生，都没有明显的区别。Riva和Laitkorpi总结了移动环境中超出典型REST设计的挑战和约束[9]。其中一个约束是离线/在线行为。他们指出，对于移动设备来说，网络连接不稳定是很常见的。因此，移动服务必须定义一种支持离线操作的策略。由于他们正在使用REST设计移动服务，他们认为离线支持适用于RESTful系统。然而，他们的解决方案中没有任何明确的支持在离线状态下处理请求的功能。05种离线支持的层次结构0在研究问题Q2中，我们要求实现RESTful客户端的离线支持的适当软件设计。换句话说，我们要求根据特定要求提供不同级别的离线支持层次结构。我们提出了一个以级别为导向的架构，如图1所示。最低级别代表缓存，并使客户端能够处理读操作。除了Fielding将缓存约束定义为减少网络流量的策略外，缓存还可以看作是离线处理请求的策略[2]。为了实现第二级别的离线支持，必须支持幂等操作。HTTP规范定义了GET、PUT和DELETE方法必须是幂等的[4]。因此，这些请求应该在此级别上可处理。客户端将需要一个队列来存储所有离线发出的请求。由于缓存默认是瞬态的，因此在此级别上必须是持久的，以允许客户端重新启动。查询操作也是幂等的，但在此级别内不予考虑。处理创建、检索、更新和删除（CRUD）操作定义在第三级别上。创建操作并不总是幂等的。因此，客户端和服务器必须确保这些请求不会被多次执行。客户端需要额外的知识来创建包含所有相关信息（如标识符）的临时资源。在同步期间，必须从缓存中删除临时资源。在创建操作之后发送的请求必须重定向到正确的URI。第四级别现在还包括查询操作。在客户端上无法保证所有数据都可在本地缓存中使用。如果离线执行，查询只能返回有限的资源集合。客户端不知道请求在在线模式下是否会返回相同的集合。除了前面的级别，客户端还需要支持分页，即只返回有限数量的结果，而不是所有结果。第五级别专门用于决定复杂业务逻辑是仅在原始服务器上可用还是在客户端上也可用。原始服务器的完全克隆将实现第六级别。在此级别上必须进行最具体的实现。此外，所有功能都必须在客户端上实现。这就是为什么最高级别是一个永远无法达到的乌托邦。06推导离线支持 6.1底层模型概述0研讨会：第九届Web API和服务架构国际研讨会WWW 2018，2018年4月23日至27日，法国里昂18770缓存0幂等操作0非幂等操作0带分页的查询0复杂的计算功能0与服务器完全相同的克隆0支持的功能0通用解决方案0图1：离线支持的六级层次结构。0Reprs 是一个有限的资源表示集合：Reprs � data × P ( Metas)，其中一个元数据元素定义了表示的媒体类型。接下来，Ops是一个有限的资源操作方法集合。ε-NFA的状态集S是应用程序状态，其中应用程序状态被定义为一个非空且有序的表示集合S � P (Reprs )−{}。除了Zuzak等人之外，我们还在状态的定义中包括了Ops。因此，一个应用程序对于操作和检索表示有不同的状态。此外，初始状态s 0表示初始应用程序状态，称为调度器状态。Zuzak等人还定义了接受状态集。在我们看来，一个RESTful系统不包含这样的接受状态，因为它运行直到被取消部署。因此，F为空集。ε-NFA的输入符号集Σ表示请求Reqs及其对应的链接类型LTypes，Σ � Reqs ×LTypes。转移函数δ表示将输入符号转换为请求、处理请求并将响应表示集成到下一个应用程序状态中，δ：S × ( Reqs × LTypes ) → P( S )。06.2 派生代理模型0我们区分客户端的原始服务器和代理。如果RESTful系统需要离线工作，所有请求将由代理处理。原始服务器负责将请求转换为响应，代理在离线工作时也必须将请求转换为响应。我们为离线模式定义了两种不同的限制：功能限制和数据限制。代理的ε-NFA是原始ε-NFA的子集。然而，如果原始服务器只提供创建、检索、更新和删除（CRUD）操作，代理ε-NFA可能包含原始服务器的所有状态。处理图像和创建PDF文件是功能限制的两个示例。处理这些功能限制的每个状态必须从代理ε-NFA中删除。还必须考虑由于缺少可用性而引起的数据限制。这可能是统计评估的情况，也可能只是查询端点的情况。因此，必须对每个状态进行评估，以确定它是否返回资源集合。如果使用缓存的数据子集足够，该状态可以是代理ε-NFA的一部分。如果处理请求需要所有数据，该状态必须从代理中删除。通过使用Zuzak、Budiselic和Delac的模型，我们定义了一个函数Φ。该函数使用原始ε-NFA作为输入，并0将其转换为代理的ε-NFA，Φ( M Origin ) → MProxy。由于两个机器都被描述为元组(S, Σ, s 0, δ,F)，函数Φ为元组的每个元素定义了规则。没有功能和数据限制的状态是代理的有限状态集的一部分。功能限制可以通过媒体类型进行过滤。状态是一个非空的、有序的表示集合，而表示至少包含媒体类型作为元数据键值对。因此，函数mtype ( s )返回表示的媒体类型。MTypes Online是只能在线模式下提供的媒体类型的有限集合。函数count ( s )验证离线模式下是否有足够的数据，以便在响应中返回一个非空的、有序的表示集合。筛选原始状态的规则定义如下：0S Proxy = { s | s ∈ S Oriдin0mtype ( s ) 是指表示的媒体类型，MTypes Online 是只能在线提供的媒体类型的有限集合，count( s ) 验证离线模式下是否有足够的数据，以便在响应中返回一个非空的、有序的表示集合。0由于额外的限制，可能需要从代理中删除一些输入元素。由于输入元素被定义为Reqs和LTypes的组合，可以使用LType来决定是否将输入元素包含在代理中。因此，我们定义了一个函数ltype ( σ)，它返回输入元素的LType。LTypes Online是只能在线模式下提供的链接类型的有限集合。函数Φ使用以下规则来筛选输入元素：0Σ 代理 = {0σ | σ ∈ Σ 原始 \ { ltype ( σ ) ∈ LTypes Online }} (2)0状态机的初始状态或调度程序对于原始和代理是相同的。调度程序包含关于下一个可用状态的信息。因此，不需要数据，也没有功能限制。可以通过Φ的定义规则来确保调度程序状态不会从代理中删除：0s 0 代理 = s 0 原始 (3)0过渡函数δ也通过Φ进行转换。将请求中的输入符号翻译、请求到响应的处理以及将响应表示集成到下一个应用状态中被定义为S × Σ →P(S)。由于一些缺失的状态和输入，代理可能具有较小的幂集。0Track: 第九届Web API和服务架构国际研讨会 WWW 2018，2018年4月23日至27日，法国里昂18780a）0b）0REST API 手动使用Φ实现评估0模型自动使用Φ生成的代理部署0图2：a）我们用于验证我们的工作的方法。我们手动在现有的RESTAPI上使用定义的函数Φ。然后我们根据Φ返回的有限状态机首次实现了代理层。最后，我们评估了代理层。b）描述了未来工作中的方法，其中代理是自动生成的。0元素，因此过渡函数本身必须进行过滤：0δ 代理 = { ( s , σ ) | s ∈ S 代理 ∧ σ ∈ Σ 代理 ∧ ( s , σ ) ∈ δ原始 } (4)0如果按照Zuzak等人对接受状态的定义，接受状态只应包含状态s ∈ S代理。由于我们有不同的观点，我们的接受状态集合在代理和原始中都为空。因此，我们定义了以下规则：0F 代理 = F 原始 (5)0函数Φ将原始服务器的任何ε-NFA转换为客户端代理的ε-NFA。这使得开发人员可以在他们的RESTful系统中实现离线模式。06.3 使用转换函数0图2在a）下展示了我们方法的下一步：首先，我们必须定义一个应用示例。然后，原始ε-NFA将通过手动应用函数Φ转换为代理ε-NFA。然后实现和评估生成的代理。如果代理在离线模式下能够支持应用程序，我们认为Φ是正确的。07 一个离线框架0本节将描述我们用作示例实现的RESTful系统。然后，我们通过手动应用函数Φ推导出代理ε-NFA。因此，使用第6.3节中描述的规则集。本节还讨论了实现所需的所有相关概念。图3显示了示例应用程序的ε-NFA，为了清晰起见，它不包含错误情况的转换。示例应用程序的主要资源是用户，子资源是待办事项。待办事项子资源的状态被总结为星号，因为它们与用户资源的CRUD状态类似。创建新用户需要用户名、电子邮件地址和密码等信息。然而，在检索时返回的表示不应包含密码信息。因此，我们为用户资源定义了两种媒体类型。待办事项资源只需要一种表示，因此只有一种媒体类型。输入元素被定义为请求及其相应的链接类型。输入元素可以影响不同的资源。然而，它们可以根据它们的LType进行分组，因为相同的LType对不同的资源具有等效的影响。下一步是手动应用函数Φ。因此，必须过滤有限状态集合和有限输入元素集合。根据定义的规则，我们删除了状态0用于个人资料图片和密码。此外，删除了具有相应链接类型的输入元素。图3显示了代理的ε-NFA的结果，虚线左侧。派生的代理将作为评估的原型实现。代理应该在我们的层次结构的第四级上启用离线支持。第一级的关键组件是缓存。由于示例应用程序的媒体类型基于JSON，缓存组件应能够处理有限的键值对集合。第二级要求缓存是持久的，以允许客户端应用程序在重新启动时不丢失当前数据状态。然而，为了简单起见，我们只实现了一个内存缓存的原型。另一个组件必须将所有离线发出的请求排队。稍后可以将排队的请求重新发送到服务器。第四级还可以处理可能导致冲突的非幂等请求。此外，如果多个用户正在更新相同的资源，可能会出现丢失更新的问题。因此，代理实现必须检测到这些冲突。如果检测到冲突，代理必须自行解决或使用回调函数向应用程序请求帮助。请求执行本身的组件必须解释传入的请求并操作缓存数据，同时处理查询。因此，需要一个用于过滤缓存资源和启用分页的组件。08讨论8.1实现原型0为了实现RESTful客户端的透明性，我们决定装饰一个现有的HTTP客户端。请求处理过程如图4所示。请求处理程序确定客户端是否在线。在线模式下，请求将直接发送到原始服务器。离线模式下，所有请求将被重定向到代理。代理将根据缓存的资源（如果可能）响应请求。然后，将请求排队以供稍后同步。GET请求不会存储在队列中，因为它们已经由代理回答，并且不会修改资源的表示。一旦客户端再次上线，队列将与原始服务器同步。离线支持是通过状态实现的。每种HTTP方法都有一个客户端状态。每个状态都具有操作持久缓存的能力。在执行所需的CRUD操作后，构建响应。响应包含了所有超媒体链接，原始服务器本应返回的链接，除了被函数Φ删除的链接。然而，应用程序可能会发送请求到代理ε-NFA中不存在的缓存超链接。代理实现将检测到这些请求，并以状态码503 - ServiceUnavailable进行回复。0Track：第九届Web API和服务架构国际研讨会WWW 2018，2018年4月23日至27日，法国里昂18790s 00GET Users GET User0POST User0DELETE User PUT User0POST Image0GET Image0PUT Password *0origin + proxy origin only0图3：示例待办事项应用程序的有限状态机。星号表示待办子资源的默认CRUD状态，类似于用户状态。08.2测试原型0为了测试，我们实现了一个随机请求生成器，可以轻松生成数百个有效请求。此外，我们手动准备了一个内存缓存，这样我们就不必为填充缓存而烦恼。由于我们的原型不能通过OPTIONS请求动态加载所需的信息，我们还实现了应用程序特定的类。测试用例使用了两个客户端：一个离线工作，一个在线工作。由于离线客户端是测试对象，在线客户端只是在同步过程中产生一些冲突。请求生成器对每种HTTP方法使用不同的概率。由于示例应用程序专注于资源操作请求，我们增加了这些请求的概率。测试成功证明了我们的代理原型的正确性。由于代理是原始ε-NFA的子集，因此很明显代理本身也是一个RESTful系统。08.3 代理层的适用性0Fielding为REST定义了五个强制性约束条件，分层系统原则是其中之一[2]。离线支持的额外层满足了这一要求。由于代理返回所有支持离线的超媒体链接，超媒体约束也得到了满足。代理层在重放队列时必须操作一些请求。根据Fielding的说法，“中介组件可以主动转换消息的内容，因为消息是自描述的，它们的语义对中介组件是可见的。”[2,5.1.6]因此，请求的操作是允许且可能的。服务器端不必关心离线支持，因为代理不依赖于服务器。服务器不必在资源表示中为代理层提供额外的信息。如果开发人员想要为他们的RESTful系统添加离线支持，他们不必更改服务器实现。使用代理层也有一些缺点。代理层提供了自己的资源缓存。如果使用代理层的应用程序还实现了缓存，移动客户端可能会达到其内存容量。在计划为现有应用程序提供离线支持时，必须考虑此问题。如果应用程序是从头开始构建的，开发人员可以考虑在代理层之上不实现自己的缓存。另一个缺点是代理层只能处理作为代理ε-NFA输入元素的请求。如果上层请求一个无法处理的缓存超链接，代理将返回503 -服务不可用的响应。因此，代理层上面的层必须处理这些响应。如果应用程序本身实现了离线支持，这些冲突可以避免。0如果应用程序是从头开始构建的，开发人员可以考虑在代理层之上不实现自己的缓存。另一个缺点是代理层只能处理作为代理ε-NFA输入元素的请求。如果上层请求一个无法处理的缓存超链接，代理将返回503 -服务不可用的响应。因此，代理层上面的层必须处理这些响应。如果应用程序本身实现了离线支持，这些冲突可以避免。09 结论和未来工作0我们为RESTful系统实现了离线支持，以在多种场景下实现更好的用户体验。因此，我们回答了REST和离线支持是否可以结合的问题，并定义了六个级别的离线支持层次结构。借助Zuzak的形式模型，我们推导出了用于获取代理层ε-NFA的函数Φ。我们实现了从手动使用Φ得到的代理。由于我们的测试成功，我们证明了我们的模型是正确的。我们实现了Demers等人的目标[1]。由于客户端资源有限，代理中的一些功能被删除。我们实现了高可用性的读写操作，并且可以通过Etag检测冲突。该原型还遵循Gonçalves和Leitão的离线工作模型[5]。本地服务器作为代理，保存离线请求并返回离线响应。在上线时，所有保存的请求将与源服务器同步。如果客户端重新上线，它将直接将所有保存的请求发送到源服务器。实现的代理层仅作为原型使用。将来需要对原型进行重构和扩展。缓存和队列必须持久存储，以便能够重新启动客户端应用程序。此外，应用程序特定类中给出的信息可以从源服务器动态加载。代理必须理解服务器的消息并正确解析信息。将来，我们还计划将函数Φ完全自动应用于RESTful应用程序的模型。关于Schreibmann和Braun的工作，可能可以在他们的面向模型的方法中实现Φ，以实现对建模的RESTfulAPI的代理层的自动化生成[11]。图2显示了使用面向模型的方法的未来过程：所需的RESTful应用程序将是0研讨会：第九届国际Web API和服务架构研讨会WWW 2018，2018年4月23日至27日，法国里昂Track: Ninth International Workshop on Web APIs and Service Architecture WWW 2018, April 23-27, 2018, Lyon, France18800客户端0源0GET，POST，PUT，DELETE POST，PUT，DELETE0GET，POST，PUT，DELETE0离线0在线0图4：当离线工作时，客户端向代理发送请求。代理将每个POST，PUT和DELETE请求排队进行同步。GET请求可以被丢弃，因为它们不会修改表示。当在线工作时，客户端直接向源服务器发送请求。为了清晰起见，我们不包括响应。0在模型中描述后，代理将通过自动使用函数Φ生成，并最终部署。这还将使我们能够生成特定于应用程序的类和功能。因此，可能可以在我们的层次结构的第四层之上生成一个用于离线支持的代理层。生成的代理层可以在离线时提供更多功能。0参考文献0[1] A. Demers，K. Petersen，M. Spreitzer，D. Terry，M. Theimer和B.Welch。1994。Bayou架构：支持移动用户之间的数据共享。在移动计算系统和应用程序，1994年。WMCSA 1994.第一次研讨会上。2-7。[2] R.T.Fielding。2000。REST：体系结构风格和基于网络的软件体系结构的设计。博士论文。加利福尼亚大学欧文分校。[3] R.T. Fielding。2008。RESTAPI必须是超文本驱动的。（2008年10月）。http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven。[4] R.T.Fielding和J. Reschke。2014。RFC7231，超文本传输协议-HTTP/1.1：语义和内容。（2014年）。http://tools.ietf.org/html/rfc7231。[5] Edgar E. M. Gonçalves和António MenezesLeitão。2007。工作流启用的Web应用程序中的离线执行。在第6届国际会议上0信息与通信技术质量（QUATIC 2007）。204-207。[6] Edgar E. M. Gonçalves和AntónioMenezes Leitão。2009。使用CommonLisp在富领域的Web应用程序中原型化离线工作。在第六届欧洲Lisp研讨会（ELW'09）的论文集中。ACM，纽约，美国，18-27。[7] L. Richardson，M. Amundsen和S.Ruby。2013。RESTful Web APIs。O'Reilly Media。[8] L. Richardson和S.Ruby。2008。RESTful Web Services。O'Reilly Media。[9] Claudio Riva和MarkkuLaitkorpi。2009。面向服务的计算-ICSOC 2007研讨会：ICSOC2007，国际研讨会，奥地利维也纳，2007年9月17日，修订选定论文。Springer BerlinHeidelberg，第设计基于REST的移动服务，439-450。https://doi.org/10.1007/978-3-540-93851-4_42 [10] M. Satyanarayanan。2002。Coda的演变。ACM Trans. Comput.Syst. 20, 2（2002年5月），85-124。[11] Vitaliy Schreibmann和PeterBraun。2015。RESTfulAPI的模型驱动开发。在第11届Web信息系统和技术国际会议的论文集中。INSTICC，SciTePress，5-14。[12] J. Webber，S. Parastatidis和I.Robinson。2010。实践中的REST：超媒体和系统架构。O'Reilly Media。[13] IvanZuzak，Ivan Budiselic和Goran Delac。2011。Web工程：第11届国际会议，ICWE2011，塞浦路斯帕福斯，2011年6月20-24日。Springer BerlinHeidelberg，第形式建模RESTful系统使用有限状态机，346-360。