没有合适的资源?快使用搜索试试~ 我知道了~
基于模型的RESTful超媒体测试
18810验证RESTful有限状态机的超媒体特性0Henry VuWürzburg-Schweinfurt应用科学大学 Würzburghenry.vu@fhws.de0Tobias FertigWürzburg-Schweinfurt应用科学大学 Würzburgtobias.fertig@fhws.de0Peter BraunWürzburg-Schweinfurt应用科学大学 Würzburgpeter.braun@fhws.de0摘要0作为一种架构风格而不是规范或标准,REpresentational StateTransfer(REST)API的适当设计并不简单,因为开发者必须处理大量的建议和最佳实践,特别是适当应用超媒体约束需要一些丰富的经验。此外,文献中缺乏关于测试RESTfulAPI的内容,尤其是没有提到超媒体测试。为了解决这种情况,我们制定了一种基于模型驱动的软件开发(MDSD)方法来创建RESTfulAPI。随着这个项目的成熟,我们还探索了模型驱动测试(MDT)的可能性。这项工作解决了超媒体测试的挑战,并提出了使用MDT技术克服这些挑战的方法。我们展示了使用模型验证方法对RESTfulAPI进行超媒体测试的研究结果。MDT使得能够在启动任何代码生成之前验证RESTfulAPI的底层模型并确保其正确性。因此,我们可以防止将设计不良的模型转化为设计不良的RESTful API。0CCS概念0•软件及其工程→基于模型的软件工程;软件验证和验证;分层系统;客户端-服务器架构;形式化软件验证;0关键词0REST,RESTful应用程序,RESTful系统,超媒体,超媒体测试,MDSD,MDT0ACM参考格式:Henry Vu,Tobias Fertig和PeterBraun。2018。验证RESTful有限状态机的超媒体特性。在WWW'18Companion:2018年Web会议伴侣,2018年4月23日至27日,法国里昂。ACM,纽约,美国,6页。https://doi.org/10.1145/3184558.319165601 引言0在过去的几年里,Web已成为新软件系统和应用程序的事实上的部署环境。软件即服务(SaaS)模型重新定义了个人计算。0本文以知识共享署名4.0国际(CC BY4.0)许可证发表。作者保留在个人和公司网站上传播作品的权利,并附上适当的归属。WWW'18 Companion,2018年4月23日至27日,法国里昂©2018IW3C2(国际万维网会议委员会),根据知识共享CC BY 4.0许可证发布。ACM ISBN978-1-4503-5640-4/18/04。https://doi.org/10.1145/3184558.31916560如今,我们很少需要在个人电脑上安装新软件来使用服务。办公生产力应用程序和企业工具,如发票、采购和费用报销系统,已经迁移到了Web上。银行、保险和零售等行业在Web应用程序和互联网服务的出现下发生了深刻的变革[14]。WebAPI已成为这些应用程序和服务的重要支柱。虽然WebAPI的数量正在增加[1],但良好的API设计的需求比以往任何时候都更为重要。一方面,良好的API可以成为公司最重要的资产之一,因为客户在购买、编写和学习API时会投入大量资源,但另一方面,糟糕的API也可能成为公司最大的负债,因为它们会导致无休止的维护和支持[4]。2000年,Fielding[7]在他的论文中提出了一种通过使用架构约束的原则来构建基于网络的应用程序的架构设计方法,称为REpresentational StateTransfer(REST)。在其基本形式中,REST要求服务器必须遵守某些约束,如客户端-服务器、无状态、缓存、统一接口、分层系统和超媒体。自从RESTfulAPI因使用简单的统一资源标识符(URI)和超文本传输协议(HTTP)动词来构建轻量级无状态分布式服务而变得流行以来,RESTfulAPI已经变得非常受欢迎[5]。但是,那些声称构建RESTfulAPI的人经常忽视超媒体约束。Fielding在他的博客[8]中也批评称,许多现有的API被称为RESTful,尽管它们并不遵循超媒体约束。此外,由于缺乏软件框架来指导实现,RESTfulAPI的开发变得困难[16]。这些情况导致开发者社区对RESTfulAPI设计存在广泛的误解。随后,缺乏符合超媒体约束的现有RESTfulAPI。由于缺乏超媒体,对其进行测试也没有意识。RESTAPI测试的常见过程只是发送HTTP请求并验证接收到的响应[18]。一个被定义为RESTful的API在使用超媒体来建模资源之间的关系时才是完全成熟的。正如[11]所说,超媒体驱动系统转换其应用状态,或者用Fielding在他的博客[8]中的话来说,应用状态的响应必须包含一组有限的超链接,用户或自动机可以通过这些超链接获得选择并选择操作。他甚至强调,如果应用状态的引擎,以及API本身,不是由超文本驱动的,那么它就不能被称为RESTful,因此也不能被称为RESTAPI。术语Hypermedia As The Engine Of Application0论文集:第九届Web API和服务架构国际研讨会WWW 2018,2018年4月23日至27日,法国里昂218820状态(HATEOAS)存在是为了描述这个约束。这些所谓的RESTfulAPI的响应不提供任何超链接来引导客户端通过应用程序工作流程。这导致了两个主要问题:a)应用程序状态不生成任何后续的超链接,客户端被迫逐个构建这些超链接,这需要对所有API端点的先前了解,从而暴露了服务器的实现细节。b)由于没有超链接供客户端跟随,因此没有应用程序工作流程,因此它是一个静态的API。c)除了缺乏工作流程外,这种描述的客户端-服务器架构是紧密耦合的,并且很可能由于任一方的更改而中断:如果服务器更改了URI,客户端将中断,如果要修改任何客户端,服务器端点必须保持不变[15]。为了解决这些问题,我们在2015年启动了我们的项目“使用RESTful架构生成移动应用程序”(GeMARA)[13]。我们提出了一种基于模型驱动的软件开发(MDSD)方法,通过使用元模型作为输入来生成RESTful API,将RESTfulAPI开发提升到更高的抽象级别。我们提出了自己的领域特定语言(DSL)来描述模型,然后将其转换为RESTfulAPI。我们的DSL能够定义典型的RESTfulAPI组件,例如具有属性的资源和由资源和HTTP动词描述的多个应用程序状态。此外,我们可以使用超链接在应用程序状态之间进行转换,并且可以通过添加特定的授权功能来保护应用程序状态免受未经授权的访问,例如身份验证(HTTP基本身份验证或OAuth)和基于角色的访问控制。通过在我们的DSL后面封装可靠和知名的库、框架和RESTful最佳实践,我们可以强制执行一致性并实现更高的质量标准。这种方法显著加速了RESTfulAPI的开发过程。一个包含两个资源的RESTfulAPI的完整模型只需大约一百行代码。一旦编写完成,我们的模型可以通过生成器转换为可部署的源代码,声明一个完全功能的RESTfulAPI。如果手动实现,这将需要更多的工作。除此之外,开发人员不必担心实现细节,例如:选择哪种编程语言、框架、库、数据库或如何实现应用程序状态之间的超链接?随着这个项目的成熟,我们还探索了基于模型驱动的测试[6]的可能性,并实现了对我们生成的API的功能测试用例的自动生成。在2017年,我们提出了几种针对RESTful系统的超媒体测试方法[17],涉及服务器端和客户端。这项工作是这些想法的进一步发展。然而,使用元模型来描述RESTfulAPI并不能阻止API设计者犯错,例如错误命名资源或某些应用程序状态缺少转换,从而违反超媒体约束。每个应用程序状态必须至少有一个传入转换,以便客户端能够到达它,每个应用程序状态必须至少有一个传出转换,以便客户端不会陷入死胡同。因此,陷入困境的客户端必须重新启动应用程序。因此,问题可能会出现,验证这个元模型的超媒体特性是否有意义。如果有的话,我们如何区分元模型的超媒体特性。0要测试吗?该模型验证过程的目标是在触发任何源代码转换之前,在最高抽象级别上识别任何错误。02 相关工作0根据Fielding[8]的说法,RESTful系统必须是超文本驱动的,换句话说,这些系统应该被设计为有限状态机(ε-NFA)。在[20]和[9]中,作者还根据他们的理解提出了他们的ε-NFA形式模型来指定RESTfulAPI。关于REST的已建立文献,如[12],[3]和[18]几乎没有提供关于其质量保证的信息。此外,几乎没有提到超媒体测试。[18]中提到了通过发送HTTP请求和验证接收到的响应来测试RESTfulAPI。RESTfulAPI建模语言(RAML)[10]也通过提供基于DSL的形式模型来推动MDSD用于RESTfulAPI的理念。该DSL旨在以人类可读的格式描述完整的API生命周期,其中包括许多RESTful规范,如URI、授权、命名空间、媒体类型和HTTP动词。基于这个元模型,可以生成和测试一个完全功能的RESTfulAPI。然而,该模型不支持通过超链接使客户端通过应用程序导航的超媒体方面。这就是为什么这种方法违反了Fielding的超媒体约束。据我们所知,关于生成和测试超媒体系统的信息有限。我们在我们的GeMARA项目中利用给定的MDSD方法,重点研究面向RESTfulAPI的超媒体测试的模型驱动测试的可能性。0使用RESTful架构生成移动应用程序0我们在2015年引入了“使用RESTful架构生成移动应用程序”(GeMARA)项目,旨在生成符合Fielding约束的稳健RESTfulAPI和测试用例[13]。我们研究项目的目标是基于RESTful架构开发分布式移动应用程序的自动化生成器。因此,应用程序不再是编程,而是以我们自己的DSL编写的抽象模型来描述,并且可以从中生成源代码和其他工件。使用REST构建互联网规模的分布式超媒体系统需要一些深入的知识,特别是在设计阶段。REST已经成为一个重要的范式,但不幸的是,对不同的人来说,它意味着不同的东西。有些人称其为标准,有些人称其为规范,而REST纯粹主义者和其创造者Fielding则认为它是一种架构风格。因此,为了纠正这些误解,我们仔细分析了Fielding的论文[7],从我们在过去几年中实施多个RESTfulAPI的经验中推导出我们模型的REST关键组件。重点在于开发一个元模型,能够以方便的方式描述REST的关键组件,并通过超媒体形成它们的关系,同时考虑所有其他REST约束。我们元模型中描述RESTfulAPI的最重要组件是应用程序状态。应用程序状态是一个HTTP方法和一个资源的配对。它表示访问资源的有效REST请求[33]。图1显示了表达我们应用程序状态概念的简化类图。此外,RESTful系统中的一个核心关键元素是资源。重要的是要注意,资源不是存储对象,而是一个概念实体[2]。资源表示单个对象或对象的集合。HTTP动词的意图应该是固定的,开发人员不应该自由选择错误的动词。创建、读取、更新和删除(CRUD)资源的四个基本操作被映射到四个HTTP动词POST、GET、PUT和DELETE。根据HTTP规范[19],这种映射是明确的。过渡是我们建模应用程序状态之间关系的正式方式。客户端可以通过过渡从一个应用程序状态导航到另一个应用程序状态。从技术上讲,过渡由超链接、媒体类型和关系类型组成。关系类型类似于HTML链接标签的rel属性。通过添加特定的授权功能,例如基于角色的访问控制和使用HTTPBasic或OAuth进行身份验证,可以保护我们的应用程序状态免受未经授权的访问[13]。0研讨会:第九届Web API和服务架构国际研讨会WWW 2018,2018年4月23日至27日,法国里昂318830我们在2015年引入了“使用RESTful架构生成移动应用程序”(GeMARA)项目,旨在生成符合Fielding约束的稳健RESTfulAPI和测试用例[13]。我们研究项目的目标是基于RESTful架构开发分布式移动应用程序的自动化生成器。因此,应用程序不再是编程,而是以我们自己的DSL编写的抽象模型来描述,并且可以从中生成源代码和其他工件。使用REST构建互联网规模的分布式超媒体系统需要一些深入的知识,特别是在设计阶段。REST已经成为一个重要的范式,但不幸的是,对不同的人来说,它意味着不同的东西。有些人称其为标准,有些人称其为规范,而REST纯粹主义者和其创造者Fielding则认为它是一种架构风格。因此,为了纠正这些误解,我们仔细分析了Fielding的论文[7],从我们在过去几年中实施多个RESTfulAPI的经验中推导出我们模型的REST关键组件。重点在于开发一个元模型,能够以方便的方式描述REST的关键组件,并通过超媒体形成它们的关系,同时考虑所有其他REST约束。我们元模型中描述RESTfulAPI的最重要组件是应用程序状态。应用程序状态是一个HTTP方法和一个资源的配对。它表示访问资源的有效REST请求[33]。图1显示了表达我们应用程序状态概念的简化类图。此外,RESTful系统中的一个核心关键元素是资源。重要的是要注意,资源不是存储对象,而是一个概念实体[2]。资源表示单个对象或对象的集合。HTTP动词的意图应该是固定的,开发人员不应该自由选择错误的动词。创建、读取、更新和删除(CRUD)资源的四个基本操作被映射到四个HTTP动词POST、GET、PUT和DELETE。根据HTTP规范[19],这种映射是明确的。过渡是我们建模应用程序状态之间关系的正式方式。客户端可以通过过渡从一个应用程序状态导航到另一个应用程序状态。从技术上讲,过渡由超链接、媒体类型和关系类型组成。关系类型类似于HTML链接标签的rel属性。通过添加特定的授权功能,例如基于角色的访问控制和使用HTTPBasic或OAuth进行身份验证,可以保护我们的应用程序状态免受未经授权的访问[13]。0转换0授权0应用程序状态0HTTP方法0资源0图1:来自[13]的应用程序状态的简化UML类图04个超媒体特征0由于这项工作致力于Fielding的超媒体约束以及如何使用基于模型的方法来确保其存在,我们将讨论有关其ε-NFA形式定义的进一步细节。我们的第一个挑战是确定我们的元模型是否是ε-NFA。如前所述,RESTfulAPI受益于超媒体约束,因为它引入了应用程序工作流,使API的设计更加方便。缺乏这个特性,API只是静态的,因此强制客户端在正确的顺序中硬编码每个API调用。ε-NFA的概念围绕着有限数量的状态和可能的状态转换。用REST术语来说,客户端在任何给定时间只能处于一个状态,并且只能通过导航通过有向转换来更改其当前状态。ε-NFA的合规性意味着应用程序中的每个状态都是可访问的。为了简化理解,有必要提供一个应用程序示例,这将是演示我们后续方法的基础。假设我们想构建一个电子商务0平台 -一个在线销售商品的商店。用户可以创建、更新或删除商品。我们将通过UML类图在图2中解释该应用程序的资源。用户资源保持简单,只有一个数据类型为字符串的userName属性和一个数据类型为Password的password属性用于身份验证。商店资源有一个name属性和一个website属性,都是字符串类型,还有一个商品的子资源列表。商品子资源由name(字符串)和price(浮点数)组成。这个示例代表了电子商务领域中的一个典型Web应用程序。为了满足超媒体测试的目的,我们将这个应用程序设计为一个具有常见RESTfulAPI的所有必备功能的模型,如主资源和子资源、应用程序状态、转换。因此,我们将把我们后面的解决方案方法引用到这个示例中。0用户0-username: 字符串-password: 密码0商店0-name: 字符串-website: 字符串-items: 列表- 0商品0-name: 字符串-price: 浮点数0图2:应用程序示例的UML类图0我们模型(GeMARA)的验证过程的主要目标是确保我们的模型生成的每个RESTfulAPI都是ε-NFA。我们的模型有一个调度器状态和多个应用程序状态。调度器状态表示ε-NFA的初始状态。每个应用程序状态由HTTP动词和资源定义。客户端可以通过转换从一个应用程序状态导航到另一个应用程序状态。转换由超链接、媒体类型和关系类型定义。第一个挑战是检查我们的模型是否符合ε-NFA。客户端应该能够从调度器状态开始,访问每个应用程序状态,并返回到调度器状态而不会陷入死胡同。图3显示了一个示例ε-NFA,其中包含我们应用程序示例的可能状态。为了清晰起见,我们省略了从每个状态返回到调度器状态的转换和自指转换。经过检查,这个示例中存在两个问题。首先,从DELETEShop应用程序状态缺少一个外向转换。这将导致客户端在选择和删除商店后被卡住。其次,客户端无法到达PUTShop应用程序状态,因为没有导向它的转换。0Track: 第九届Web API和服务架构国际研讨会WWW 2018,2018年4月23日-27日,法国里昂418840开始0获取商店获取商店0修改商店0删除商店0获取物品0添加商店0图3:具有缺失转换的API的ε-NFA示例。0模型测试的第二个目标是执行超媒体语义检查。在超媒体系统中,有一些状态到状态的转换被认为是糟糕的设计,因此应该避免。例如,DELETE状态不应导致PUT SingleResource状态,因为从API设计者的角度来看,这种组合没有意义。在删除单个资源后,客户端应导航到哪个具体的单个资源?相反,最好将客户端引导到资源的GET集合状态。为了避免这种糟糕的设计决策,在模型验证过程之后,我们执行超媒体语义检查。该过程能够在我们的模型中搜索此类不适当的组合,并通知API设计者。05超媒体特性的验证0我们MDSD方法的模型由文本领域特定语言(DSL)描述。该模型还体现了API的构建计划,这意味着其他专家可以对其进行同行评审以检查其正确性。虽然可以手动进行此验证过程,但不应在没有现有工具的帮助下进行。由于我们的模型已经提供了关于每个应用程序状态及其可能转换的具体信息,我们能够执行自动验证过程。首先,我们检查我们的模型是否符合ε-NFA。ε-NFA符合性意味着应用程序中的每个状态都是可访问的,并且没有死状态使客户端陷入困境。此测试应在转换过程之前直接执行。算法很简单:循环检查模型中的每个应用程序状态。每当存在缺失的入站或出站转换时,它将抛出适当的异常,以使API设计者意识到这一点。如果模型正确 -意味着每个应用程序状态至少有一个入站和一个出站转换 -则可以开始转换过程。这个ε-NFA检查的目标是在触发任何源代码转换之前在最高抽象级别上识别任何错误。这确保了每个状态都是可达的,没有死胡同,从而违反了Fielding的超媒体约束。例如,如果我们看一下图3,在应用程序中的死胡同0删除商店和不可达的应用状态PUTShop将被检测到。在实现层面上,我们的元模型由Java对象组成。该模型包含了生成器转换为RESTfulAPI所需的所有必要信息。ε-NFA检查过程利用此功能,能够从模型中提取所有所需信息,以进行验证,而无需任何额外的外部库。现在,我们必须确保在我们的元模型中没有任何不适当的状态转换。这应该代表了任何API设计者避免糟糕设计决策的框架。显然,需要更多的工作来解决这个问题,以便创建更通用的指南,以确定转换是否不适当以及设计是否被认为是好的。到目前为止,我们的研究已经研究了一些特定案例。我们的元模型能够描述六种不同类型的状态:GETDispatcher State、GET Single Resource、GET CollectionResource、POST Single Resource、PUT SingleResource和DELETE SingleResource。由于我们的元模型将ε-NFA与有向状态转换相结合,我们查看每个单独的状态类型,并讨论它是否具有不适当的出站转换:GET Dispatcher State:该状态表示RESTfulAPI的入口点。因此,它应该直接链接到GET Single Resource、GETCollection Resource或POST SingleResource。其他任何配置都没有意义,因为PUT状态或DELETE状态需要客户端预先选择一个现有资源来修改或删除它。GET SingleResource:该状态可以直接链接到任何其他状态类型,因为该状态没有不适当的出站转换。从GET SingleResource,我们可以修改它,删除它或转到另一个资源,具体取决于预期的应用程序工作流程。GET CollectionResource:该状态不应直接链接到DELETE状态或PUT状态。位于此应用程序状态的客户端获取特定资源的一组实体。DELETE状态或PUT状态将假定客户端希望一次操作整个集合。但是,有特定的用例要求这种类型的应用程序工作流程。POST SingleResource:在创建实体后,不应将客户端导向DELETE状态,因为在创建实体后立即删除实体是不常见的。PUT SingleResource:PUT状态应直接返回修改的实体,即GET SingleResource状态。应避免从PUT状态到DELETE状态的出站转换,原因如上所述。DELETE SingleResource:在删除实体后,不应将客户端导向PUT状态,因为PUT状态要求客户端预先选择实体以进行修改。将客户端重定向到下一个单一资源或资源集合将更方便。图4示例了我们电子商务应用程序中适当的工作流程。0Track: 第九届国际Web API和服务架构研讨会WWW 2018,2018年4月23日至27日,法国里昂518850开始0GET 商店 POST 商店0GET 商店 PUT 商店 DELETE 商店0图4:一个适当的应用程序工作流程示例。06 评估和讨论0本工作的主要目标是使用我们的MDSD方法验证RESTfulε-NFA的超媒体特性。超媒体对于RESTful系统至关重要,因为它区分了具有预定义应用程序工作流程的静态API和具有超媒体链接(HATEOAS)的RESTfulAPI。我们的验证过程揭示了在最高抽象级别上的错误,确保模型在触发源代码转换之前被设计为ε-NFA。此外,它在出现错误时通知API设计人员有任何问题。由于我们的元模型本身由Java对象组成,我们可以简单地访问其属性并循环遍历每个应用程序状态,以确保每个应用程序状态至少有一个传出和一个传入的转换。每次API设计人员触发其模型的代码转换时,ε-NFA检查将被启动。如果缺少转换,它将提供适当的异常,让API设计人员知道哪个应用程序状态有问题,以及它是缺少传入转换还是传出转换,或者两者都缺少。如果没有缺少转换,代码转换可以开始。本工作还引入了超媒体语义检查,为设计RESTfulAPI提供了指导方针。这是一组规则,概述了不适当的状态到状态转换。本工作的另一个目的是教育API设计人员避免糟糕的设计决策,从而使应用程序工作流程更加方便。随着我们的GeMARA元模型的进一步发展,这些规则可以扩展。目前,这个超媒体语义检查发生在ε-NFA检查之后和代码转换过程之前。每当违反其中一条规则时,它会产生一个警告。然而,我们关于基于模型驱动的模型测试的发现证明存在局限性。我们能够访问我们的模型的属性,因为它的格式是基于Java对象的实现级别。但是,任何依赖于图形模型格式或其他DSL的其他基于模型驱动的方法可能需要额外的调查来应用自动模型测试。07 结论和未来工作0在这项工作中,我们指出许多API被称为RESTful,即使它们不符合Fielding的超媒体约束。0一个RESTfulAPI需要使用超媒体来引导其应用程序工作流程,否则它只能满足静态服务器的要求。尽管它很重要,但这仍然是文献中缺少的一个主题。为了简化RESTfulAPI的开发过程,我们在2015年开始了我们的项目GeMARA,其中我们提出了一种基于模型驱动的方法来创建RESTfulAPI。我们的愿景是生成健壮的RESTfulAPI以及测试来确保Fielding的超媒体约束。我们通过执行自动超媒体检查,确保我们的模型被设计为ε-NFA。手动模型审查耗时且难以维护,特别是对于拥有数十个资源和数百个应用程序状态的模型。这个模型验证过程是一个有用的工具,因为它可以防止源代码生成出现错误设计的模型,并使API设计人员意识到他们的错误。在实现超媒体检查的过程中,我们意识到我们的模型提供了更多的可能性来进行广泛的模型验证。我们发现我们可以检查超媒体语义,以防止设置某些状态到状态的转换。这个主题值得进一步研究,因为我们必须小心不要过度概括。因此,需要更多的时间来创建更通用的指导原则,无论何时一个转换是不合适的,何时一个模型设计被认为是好的。此外,模型分析还可以执行其他任务,例如按约定检查资源、状态或转换的命名。这些模型测试可以为更好的模型设计和最终生成更好的RESTfulAPI做出贡献。确保静态元模型是一个正确的ε-NFA是不够的。我们还必须测试从任何符合ε-NFA的模型生成的源代码,如[17]所述。代码生成器可能存在错误,因此会将正确的模型转换为错误的源代码。这意味着在超媒体术语中,即使模型中的每个应用程序状态至少有一个传入和一个传出的转换,从这个符合ε-NFA的模型生成的实际API仍然可能在某些应用程序状态下缺少转换。应用程序状态的响应必须包含一组有限的超链接,通过这些超链接用户或自动机可以获取选择并选择操作[8]。这意味着我们必须检查每个应用程序状态的响应是否在运行时提供了正确的有限超链接集。RESTfulAPI可以被第三方客户端使用。正确使用超媒体的客户端在服务器更新时需要较少的手动调整。一旦我们的服务器端超媒体测试过程完全自动化,我们将解决客户端超媒体测试的问题。我们在客户端测试中的动机是确定客户端是否是超媒体驱动的。如果运行的客户端可以处理服务器内的某些类型的更改,这个假设可以得到确认。我们将讨论服务器可以发生多大程度的变化而不会对超媒体客户端产生负面影响。在我们的未来工作中,我们将探讨将基于用户验收标准生成测试用例的更高抽象级别的自动化服务器更新的可行性。一个长期的目标是将基于模型驱动的软件质量保证提升到更高的抽象级别。例如,我们可以通过根据用户验收标准生成测试用例来开始在更高抽象级别上工作。用户验收测试是一项昂贵且耗时的任务。我们的爬虫可以0研讨会: 第九届Web API和服务架构国际研讨会 WWW 2018, 2018年4月23日至27日, 法国里昂618860生成一系列输入序列以模仿用户行为,以测试一般用例场景。这将大大减少工作量。0参考文献0[1] 2017. 2005年以来Web API的增长。http://www.programmableweb.com/api-research. (2017). 最后访问于2018年1月23日。[2] M. Amundsen. 2017.REST简介。http://exyus.com/articles/ rest-the-short-version/. (2017).最后访问于2018年1月23日。[3] Mike Amundsen. 2017. RESTful Web Clients -通过超媒体实现重用 . O’Reilly Media, Sebastopol. [4] Joshua Bloch. 2014.设计良好的API及其重要性。http://static.googleusercontent.com/media/research.google.com/en//pubs/ archive/32713.pdf. (2014). 最后访问于2018年1月23日。[5] H.Ed-douibi, J. L. C. Izquierdo, M. Tisi A. GÃşmez, and J. Cabot. 2016. EMF-REST:从模型生成RESTful API。在第31届年度应用计算机学术会议论文集中。SAC’2016,SciTePress. [6] Tobias Fertig and Peter Braun. 2015. RESTfulAPI的模型驱动测试。在第24届国际万维网会议伴随会议论文集中 (WWW ’15Companion) . International World Wide Web Conferences Steering Committee,Republic and Canton of Geneva, Switzerland, 1497–1502. https://doi.org/10.1145/2740908.2743045 [7] R.T. Fielding. 2000. REST:架构风格和基于网络的软件架构设计 . 博士论文. 加利福尼亚大学欧文分校. [8] R.T.Fielding. 2008. REST API必须是超文本驱动的。http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven. (2008年10月).最后访问于2018年1月23日。[9] Antonio Garrote HernÃąndez and MarÃŋa N.Moreno GarcÃŋa. 2010.RESTful语义Web服务的正式定义。在第一届RESTful设计国际研讨会论文集中 (WS-REST’10) . ACM, 纽约, 纽约, 美国,039–45. https://doi.org/10.1145/1798354.1798384 [10] M. Hevery, J. Musser, P.Rexer, U. Sarid, and I. Lazarov. 2017. RAML. http: //raml.org/. (2017).最后访问于2018年1月23日。[11] Savas Parastatidis, G. S. Jim Webber, and I. S.Robinson. 2010.超媒体在分布式系统开发中的作用。在第一届RESTful设计国际研讨会论文集中。WS-REST,ACM. [12] L. Richardson, M. Amundsen, and S. Ruby. 2013. RESTful Web APIs .O’Reilly Media. https://books.google.de/books?id=ZXDGAAAAQBAJ [13] V.Schreibmann and P. Braun. 2015. RESTfulAPI的模型驱动开发。在第11届Web信息系统和技术国际会议论文集中。INSTICC,SciTePress. [14] Antero Taivalsaari and Tommi Mikkonen. 2017. 作为软件平台的Web:十年后。在第13届Web信息系统和技术国际会议论文集中。INSTICC, SciTePress. [15]Stefan Ulrich. 2014. 想要REST,就必须认真对待HATEOAS。https://jaxenter.de/wer-rest-will-muss-mit-hateoas-ernst-machen-489. (2014).最后访问于2018年1月23日。[16] S. Vinoski. 2008. RESTful Web服务开发清单。IEEE互联网计算 12, 6 (Nov 2008), 96–95. https://doi.org/10.1109/MIC.2008.130 [17]H. Vu, T. Fertig, and P. Braun. 2017.面向RESTful系统的模型驱动超媒体测试。在第13届Web信息系统和技术国际会议论文集中。[18] Jim Webber, Savas Parastatidis, and Ian Robinson. 2010. REST实践 -超媒体和系统架构 . "O’Reilly Media, Inc.", Sebastopol. [19] www.w3.org. 2018.HTTP规范。https://www.w3.org/Protocols/rfc2616/ rfc2616-sec9.html. (2018).最后访问于2018年1月22日。[20] Ivan Zuzak, Ivan Budiselic, and Goran Delac. 2011.Web Engineering: 11th Inter- national Conference, ICWE 2011, Paphos, Cyprus, June20-24, 2011 . Springer Berlin Heidelberg, Chapter Formal Modeling of RESTfulSystems Using Finite-State Machines, 346–360.https://doi.org/10.1007/978-3-642-22233-7_240研讨会:第九届国际Web API和服务架构研讨会WWW 2018,2018年4月23日至27日,法国里昂
下载后可阅读完整内容,剩余1页未读,立即下载
![rar](https://img-home.csdnimg.cn/images/20210720083606.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![zip](https://img-home.csdnimg.cn/images/20210720083736.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://csdnimg.cn/download_wenku/file_type_ask_c1.png)
![](https://profile-avatar.csdnimg.cn/default.jpg!1)
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
我的内容管理 收起
我的资源 快来上传第一个资源
我的收益
登录查看自己的收益我的积分 登录查看自己的积分
我的C币 登录后查看C币余额
我的收藏
我的下载
下载帮助
![](https://csdnimg.cn/release/wenkucmsfe/public/img/voice.245cc511.png)
会员权益专享
最新资源
- 电力电子与电力传动专业《电子技术基础》期末考试试题
- 电力电子技术期末考试题:电力客户与服务管理专业
- 电力系统自动化《电力电子技术》期末考卷习题精选
- 电力系统自动化专业《电力电子技术》期末考试试题
- 电子信息专业《电子技术》期末考试试题解析
- 电子与信息技术专业《电子技术》期末考试试题概览
- 电子信息工程《电子技术》期末考卷习题集
- 电子信息工程专业《电子技术》期末考试试题解析
- 电子信息工程《电工与电子技术》期末考试试题解析
- 电子信息工程专业《电子技术基础》期末考试计算题解析
- 电子技术期末考试题试卷(试卷B)——电子技术应用专业
- 电子科技专业《电力电子技术》期末考试填空题精选
- 2020-21秋《电力电子技术》电机电器智能化期末试题解析
- 电气工程及其自动化专业《电子技术》期末考试题(卷六)
- 电气工程专业《电子技术基础》期末考试试题解析
- 电气自动化专业《电子技术》期末考试试题解析
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035711.png)
![](https://img-home.csdnimg.cn/images/20220527035111.png)
安全验证
文档复制为VIP权益,开通VIP直接复制
![](https://csdnimg.cn/release/wenkucmsfe/public/img/green-success.6a4acb44.png)