英语原文共 6 页，剩余内容已隐藏，支付完成后下载完整资料
在JavaScript中静态检查Web API请求
Erik Wittern*, Annie T. T. Ying*, Yunhui Zheng*, Julian Dolby, Jim A. Laredo
IBM T. J. Watson Research Center, Yorktown Heights, NY, USA
Email: {witternj, aying, zhengyu, dolby, laredo}@us.ibm.com
摘要：许多JavaScript应用程序对web APIs执行HTTP请求，依靠请求URL，HTTP方法和请求通过字符串操作正确构建的数据。传统的编译错误检查（例如在Java中调用不存在的方法）不能用于检查这些请求是否符合web API的要求。
关键词：静态分析；JavaScript；Web APIs
一、简介
程序员使用各种各样可公开访问的web服务来编写应用程序。IBM的API Harmony[1][2]，Mashape的Public APIs[3]或Programmable Web [4]等产品目录列出了成千上万个被web服务公开的Web应用编程接口（web API）。应用程序通过使用URL所支持的其中一种HTTP方法将HTTP请求发送到专用URL来调用web APIs; 所需数据作为查询或路径参数或HTTP请求主体发送。URL，HTTP方法和要发送的数据基本上都是字符串，它们由应用程序中的字符串操作构成。图1显示了一种执行这些操作的JavaScript应用程序的典型截图。
当请求的目标URL不存在或发送的数据不符合web API的要求，则会发生运行时错误。web API的这种普遍的调用机制（依赖于字符串URL，HTTP方法以及字符串输入和输出）不允许进行类型安全性检查。换句话说，对于编写调用Web API代码的程序员来说，传统的编译错误检查是不可用的。最近的一项研究发现，被分析的大量移动应用程序将因其所使用的web API的变化而出现错误[5]。随着（网络）应用程序越来越多地使用JavaScript等动态语言开发，情况将会变得更糟，这些语言通常也很少有静态检查。
举一个例子，我们发现GitHub中的代码错误地试图向https://api. spotify.com/v1/seach发出请求，而不是调用以/search结尾的正确URL。我们发现的另一个示例（图1）试图调用已弃用的谷歌地图引擎API。希望能够避免这些错误的程序员可以通过查阅API（在线）文档或正式的web API规范来人工评估web API请求的正确性。如OpenAPI规范（以前被称为Swagger，我们会将这个名称用于本文其余部分）一类的规范可以由API供应商提供或由第三方创建，以便记录有效的URL，HTTP方法以及输入和输出。
图1向谷歌地图引擎 API发送请求的代码片段;
可以将易错又繁琐的人工检查变为自动检查的工具应具有以下两个理想的功能：
- 这些工具应该静态分析JavaScript源代码，从而自动识别HTTP请求并检索这些被编码为字符串并使用典型字符串操作（如串联）所创建的相关的URL，HTTP方法和数据，此外，因为字符串可以跨功能组装，所以分析必须是跨程序的。
- 作为输入，这些工具应利用可用的规范，如用Swagger来定义有效的URL，HTTP方法和数据。
这些工具可以在程序员编写应用程序或在持续集成期间实时报告错误。此外，他们还可以帮助API提供商在公开可用的代码中监控其API的使用情况。
本文中，考虑到这两个特性，我们提出了一种方法，将输入的Swagger规范和静态检查JavaScript代码中的Web API请求是否符合这些规范。 我们的方法首先使用能够提取字符串的程序间静态程序分析[7]提取URL字符串，HTTP方法和来自请求的相应数据，然后检查请求是否符合公共可用的Web API规范。我们最初选择使用jQuery框架处理编写的请求，因为它的流行度--据报道，70％的网站使用jQuery框架[8]。我们方法的主要贡献在于利用现有的工作，使基于框架的JavaScript Web应用程序（即[7]，[9] - [11]）成为可能的静态整体程序分析，并将其应用于一个新的问题，检查请求是否与Web API规范一致。
我们通过检查超过6000个来自GitHub2的JavaScript文件的Web API请求与API Guru项目[12]提供的公开可用Web API规范是否一致来评估我们的方法。根据我们提供的可用Web API规范的6575个请求，在正确提取和确定请求中的URL和HTTP方法与相应的Web API规范是否一致时，我们的分析实现了96.0％的准确度。我们的方法也正确提取并确定请求数据是否与数据要求一致，有效负载数据的正确率为87.9％和查询数据的正确率为99.9％。我们系统地检查了与规范（1477个案例）不一致的所有URL和有效负载数据，发现许多的不一致是客户端代码中的错误造成的，包括对弃用API的调用，URL中的错误以及数据有效负载定义中的错误。在1477个案例中，仅有5个案例是由于我们静态分析的局限性影响了对规范中一个URL端点的请求的匹配，从而将请求错误地标记为不匹配。这些局限性还扩展到18个案例中的4个，在这些情况中，请求有效负载被错误地标记为错误匹配，并且在41个查询参数被错误地标记为不匹配的情况下，有2个是错误匹配的。这些结果表明，静态分析能足够精确地用于我们所提出的检查器，用于检查正在开发的应用程序，或用于在Web API发生变化时检查现有源代码中Web API使用的有效性。
本文的其余部分安排如下：在举例说明（第二节）之后，我们描述了我们的方法：静态分析（第三节）和检查器（第四节）。 然后，我们提出评估（第五节），相关工作（第六节），威胁（第七节）和结论（第八节）。
- 背景与示例
在本节中，我们首先介绍有关Web API及其规范的概念和术语。然后我们通过一个示例来演示我们的方法的两个步骤：我们如何使用静态分析来提取构建Web API请求的字符串（第II-A节）以及我们在避免使用Swagger规范的情况下如何检查静态分析结果（第II-B节）。
Web API是应用程序通过HTTP调用与远程资源（如数据或功能）交互的程序接口。资源由URL标识，而交互类型（例如，检索，更新，删除资源）依赖于HTTP方法。在之前的工作中，我们将URL和HTTP方法结合起来作为API端点[13]。 为了成功调用，一些端点需依赖于附加数据，例如在URL中作为路径参数发送的资源的ID，或者在HTTP请求的主体中发送的资源的新的/更新的状态。
应用程序开发人员可以通过查阅其在线文档（通常以HTML格式提供）或依靠正式的Web API规范来了解API终端的使用情况。规范定义了API的端点以及请求所需的数据和返回的数据。OpenAPI规范(Swagger) 是这些规范中的其中一种，它拥有广泛的行业支持。
图2 对Instagram API的Swagger规范的摘录
图2显示了对Instagram API的Swagger文档的摘录。例如，它定义了API的方案，它的主机和basePath，这些一起构成了API的基本URL，在这里是https://api.instagram.com/v1。Swagger使用URL模板（可能包含路径参数，例如tag-name在路径/tags/{tag-name}/media/recent中）和支持的HTTP方法来定义API属性的不同端点。对每个端点，Swagger都提供了可读的描述，参数的定义（路径和查询参数以及所需的HTTP主体），可能的响应的定义以及安全要求。定义属性中的条目描述了使用JSON模式表示法[14]或特定于Swagger的XML对象表示法向终端发送或接收数据的结构。数据定义可以从端点定义中引用，如图2中TagMediaListResponse定义的示例所示。
- 用JavaScript代码确定请求的内容
检查器的第一步是在代码中提取Web API请求的具体信息。我们采用了一种跨过程的静态分析方法，从JavaScript代码中的web API请求中提取URL和输入字符串。以图1中的代码为例，我们可以看到url变量由两个常量字符串和函数updateLocation中的aid变量组成。然后将url的值传递给sendRequest，在那里它传入jQuery.ajax调用。aid的值是一个参数，在多次运行中可能不同。因此，当我们打算提取此请求中使用的URL时，我们使用大括号将aid表示为符号值{aid}，表示该值不是静态的。总的来说，所请求的URL中提取的网址是https://www.googleapis.com/mapsengine/ v1beta2/tables/{aid}/features/batchInser。
如这个例子所示，像grep这样的简单文本搜索将不会有效，因为请求的调用位置（例如图1中的sendRequest）可能与URL条件的定义不同（图1中的updateLocation）。另外，由于URL字符串可以跨多个函数和词法作用域（例如，我们从图3中的代码摘录中提取的正确静态分析的URL ：https://api.instagram.com/v1/tags/{tag-name}/me dia/recent），解析这样的URL字符串需要复杂的数据流分析。对于可能在多个函数中创建的HTTP方法或请求数据值也是这样。
- 根据Web API规范检查请求
我们方法的第二步是检查从Web API请求提取的信息是否符合Web API
规范。
图3向Instagram API请求代码摘录
例如，我们静态分析从图3代码中提取的URL：https://api.instagram.com/v1/tags/{searchHashtag} /media/recent?client_id=1e3hellip;我们的检查将首先确定它是否与相关方法一起针对Instagram API的Swagger规范中定义的实际端点（包括searchHashtag路径参数）。此外，我们还可以检查端点是否期望client_id参数，或者是否需要其他查询参数，URL中缺少这些参数。最后，我们可以检查请求主体中发送的数据是否符合Swagger规范中的数据定义。
检查web API请求是否正确的另一个选项是执行动态分析[15]。但是Web API的调用通常需要认证（例如使用API密钥），因此使用动态分析的系统需要提供密钥来注册，甚至同意服务条款。通常，服务条款不容易被外行人理解，而且更不可能被编码成机器可读的形式，以允许程序决定是否遵守条款。最后，即使解决了关键配置问题，确保动态分析具有适当的代码覆盖率也是具有挑战性的。
三、Web API的使用与提取
我们方法的一个基本部分就是从JavaScript源代码中检测和提取web API用法。
图4Web API使用提取器概述。
图4显示了Web API使用提取器管道。输入是一个JavaScript文件。输出是web API的使用情况，包括url和JSON格式的请求有效负载。决定将一个JavaScript文件作为输入，即将分析范围设置为文件级别而不是程序级别，这是基于我们最初的观察结果，即输入字符串通常与请求在同一文件中。这一决定还支持分析轻量级，足以在开发过程中反复使用。对于本节的其余部分，我们将描述管道中的三个主要组件：
基于字段的调用图生成器：提取器将JavaScript文件作为输入并分析脚本，排除带有语法错误的文件。然后将分析脚本转换为中间表示，并构建一个近似的调用图，称为基于字段的调用图。基于字段的调用图是一个语句级调用图，它对程序中使用的每个属性的所有实例使用一个抽象，而不是像传统的调用图那样对每个抽象对象的每个属性进行抽象；即使在JavaScript的动态特性出现的情况下，这也已经被证明能够很好地用于基于框架的JavaScript web应用程序。我们使用了WALA [16]中提供的基于字段的调用图结构来实现。为了优化生成器，WALA中的调用图结构用于忽略所有不涉及函数的数据流。同时为能支持我们的字符串分析，我们将调用图构造中的数据流分析扩展到了跟踪程序中字符串的数据流。我们将脚本中的所有函数作为调用图的入口点。标准方法将事件处理程序和顶级块作为入口点。但是，如果我们要使用相同的方法，那么如果在超出分析范围的脚本中将函数注册为事件处理程序，我们在文件级别的范围分析就可能会错过入口点。
Web请求定位器：为了识别API调用，我们在调用图中查找特定于框架的模式。对于jQuery，我们处理最常见的模式，即对$.ajax，$.get和$.post的函数调用。我们注意到这些调用的指令，并将它们用作流程中下一个组件的程序间数据流分析的种子。 当脚本不包含匹配的调用语句时，我们的分析不会产生任何输出，并且管道会终止。
用于请求封送的向后切片器：在这一步中，我们提取有助于输入Web API调用的语句。从上一步中捕获的每个请求函数调用开始，我们应用标准的跨过程向后切片[17]，以缩小影响包含请求的语句的程序语句的子集
全文共13077字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13071]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
