我确定你在这里是因为你需要加载测试Json Rest API。这并不奇怪，因为Rest API现在越来越受欢迎。
这本指南的目的：帮助您进行负载测试一个Json的 REST API 通过一个具体的例子，OctoPerf的Json的REST API。
本指南将完全为您提供以下知识：
- 使用Http POST请求处理Rest API登录，
- 从Json Response中提取变量，稍后在脚本中重用它，
- 并使用JMeter Json Assertion（在JMeter 4中引入）验证Json响应。
这里没有理论，只有实践：一切都基于一个现实的Rest API（不是一个虚拟的例子）。您可以在学习本教程的同时下载示例JMX。
准备好学习？我们走吧！
休息API登录
OctoPerf平台基于Json Rest API。我们将看看如何使用JMeter模拟我们的API登录。
但是身份验证如何运作？我们如何使用JMeter模拟登录？大多数Rest API使用以下登录工作流程：
- 登录使用HTTP POST请求通过提供
username和password， - 接收临时身份验证令牌，以便以后请求标识自己，
- 发送身份验证令牌的后续请求中，典型地经由HTTP标头一样
Authorization: Bearer AUTH_TOKEN。
OctoPerf API也是如此。这与Oauth身份验证非常接近。
登录API规范
首先，让我们看看如何登录OctoPerf Application。值得庆幸的是，我们的API有一个Swagger规范：Swagger是一个提供Rest API文档的工具。
Doc指定如何通过OctoPerf的API登录
好！现在让我们检查一下使用JMeter伪造的请求：
- Http方法：必须是POST请求，带有一些post参数，（参见GET vs POST）
- Http Scheme：
https由于我们的Rest API 由SSL保护， - 主机名：
api.octoperf.com， - 路径 :(
/public/users/login登录端点路径）， -
发布参数：
然后我们应该从服务器接收一个Json Response，它应该是这样的：
{
"token": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}
在这里看到令牌？这是我们稍后将用于在Rest API上识别自己的东西。但是，首先让我们来看看JMeter HTTP请求。
执行登录
通过Rest API登录OctoPerf
在这里，我们已准备好将Login Http Request发送到我们的服务器。我刚刚隐藏了敏感信息，但这基本上就是您的帐户信息。为了调试登录，我们将使用View Results Tree Listener。
登录请求发送到服务器
我们可以看到，发送的请求是一个POST表单-urlencoded，其中包含我们的登录名和密码。这里没什么难的！现在，我们对服务器发送的Json响应感兴趣。
从服务器收到响应
精细！现在我们收到了身份验证令牌，我们可以提取它以在后续请求中重用它。
提取身份验证令牌
基于令牌的身份验证是一种简单的机制，其中令牌唯一地标识用户会话。我们需要处理这个问题，dynamic parameter以正确模拟与Json API交互的用户。
使用Json Extractor
要从服务器响应中提取身份验证令牌，我们将使用JMeter JsonPath Extractor。从响应中提取变量的过程如下：
- 服务器发回对我们的登录请求的响应，
- 甲后处理器，像JsonPath提取是继执行
- 提取器提取服务器响应的一部分并将其放入变量中
${token}。
从服务器响应中提取身份验证令牌
我们已经使用这些设置配置了JMeter Json Extractor：
- 创建变量的名称：
token，这将导致带有语法的可重用变量${token}， - Json Path表达式：
$.token，有关详细信息，请参阅示例JsonPath表达式， - 并且匹配Nr：简单地说
1，第一次出现。但我们可以把它留空。
看看我放置提取器的位置？在loginHTTP请求下。我们还添加一个Debug Sampler来查看是否正确提取了变量。
启用调试
在Debug Sampler中启用JMeter变量
通过设置JMeter的变量来true，我们启用了采样器输出变量的试运行期间。
测试提取
使用Json Extractor从服务器响应中成功提取令牌
大！Json提取器完美无缺。它token从Json响应中提取字段的值。我们现在可以${token}在后续请求中使用表达式来执行经过身份验证的请求。
让我们看看我们如何重用此令牌来告诉我们的Rest API我们是一个给定的用户。
重新注册Auth Token
我们的Rest API有许多需要身份验证的端点。这些端点提供用户工作区，项目，虚拟用户等数据。要访问受用户保护的端点，必须：
- 登录以获取身份验证令牌（就像我们预先做的那样），
Authorization: Bearer TOKEN对于每个后续请求，在http请求标头内发送身份验证令牌。
这正是我们在这里要做的。
检索用户工作区
我们现在特别感兴趣的是查询用户的工作空间。这是Workspaces API端点的一部分。
工作区从Swagger API文档中休息API端点
我们将GET使用路径向端点执行请求/workspaces/member-of。它应该返回包含用户工作空间的Json响应。这是一个示例响应：
[
{
"created": "2018-04-23T12:40:00.133Z",
"description": "This is my personal workspace.",
"id": "workspaceId",
"lastModified": "2018-04-23T12:40:00.133Z",
"name": "Personal",
"userId": "myUserId"
}
]
让我们在JMeter中创建一个HTTP请求来查询它们。这很简单，如下面的截图所示。
从JMeter调用端点成员
在这里，我们设置了一个HTTP请求来查询用户的工作区：
- Http方法：必须是GET请求，不涉及参数，
- Http Scheme：
https由于我们的Rest API 由SSL保护， - 主机名：
api.octoperf.com， - 路径：
/workspaces/member-of。
完了吗？还没。目前，如果我们不提供身份验证令牌，服务器将拒绝我们的请求。
服务器返回错误
服务器以Http 4xx错误拒绝请求：401 Unauthorized。
与403 Forbidden类似，但专门用于需要身份验证且已失败或尚未提供的情况。
我们需要通过Authorization在请求中包含标头来提供身份验证令牌。怎么样？通过向请求添加HTTP标头管理器。
添加授权标头
在Authorization标头中设置提取的令牌
记住：我们之前已经token从/public/users/login端点服务器响应中提取了。现在，是时候重用它来检索访问受保护的资源了：
- 首先，在getWorkspaces HTTP Request 下添加一个Http Header Manager，
- 添加
Authorization带有值的标头Bearer ${token}。
从服务器获得工作区
太好了！它现在正在工作！我们拥有属于已登录用户的所有工作空间。
授权标头已在请求中发送
授权标头已成功包含在请求标头中。但是，有一件令人讨厌的事情是：Json格式不正确。为什么？
大多数服务器以紧凑格式发送json，跳过缩进。这是出于性能原因（减少带宽使用和服务器CPU使用）
格式化Json响应
为了解决这个问题，JSON Formatter PostProcessor能够很好地完成这项工作。
JMeter Json Formatter后处理器
请参阅我们的JMeter插件安装指南，了解如何安装Json插件。另一个选择是使用JSR223脚本自己格式化Json 。
Json现在很漂亮！
现在，我们可以利用Json Assertion（在JMeter 4.0中引入）的强大功能来检查服务器响应。
使用Json Assertion
我们将确保服务器响应包含Personal工作区。这是Json断言的工作。要添加Json断言，请右键单击HTTP Request采样器，然后选择Add > Post Processor > Json Assertion。
组态
断言响应包含个人工作空间
Json断言配置如下：
- 断言的Json路径存在：
$.[1]['name']指第二工作区返回，并采取了name， - 另外Assert Value：选中以检查
name字段的值， - 预期价值：应该是
Personal。
执行
假设我们断言期望值是Other不是Personal。
查找名为Other的 workspaced时，Json Assertion失败
正如预期的那样，断言失败并显示以下消息：
Assertion error: false
Assertion failure: true
Assertion failure message: Value expected to be 'Other', but found 'Personal'
性能
当然，你不仅限于使用Json Assertion。如果您愿意，也可以使用JMeter Response Assertion。它在性能方面甚至是有益的，因为根据我们的断言性能比较表，响应断言比Json断言消耗更少的CPU /内存资源。
模拟动态行为
现在我们知道如何登录Json Rest API并发送访问受保护端点的请求，让我们看看如何dynamically behaving使用JMeter 模拟用户。
这是本教程的最后一部分：
- 首先，我们将提取随机工作区ID，（将
${workspaceId}） - 其次，我们将使用端点查询该工作空间的项目
/projects/by-workspace/${workspaceId}/DESIGN。
OctoPerf的Projects Rest API端点
最后一个Rest API端点让我们感兴趣。我们将从JMeter调用它，但首先我们需要提取一个随机workspaceId。
提取WorkspaceId
提取随机workspaceId
提取器配置为getWorkspaces请求的后处理器，具有以下设置：
- 创建变量的名称：
workspaceId， - Json Path表达式：
$..id， - 匹配号：
0，这是随机的。
这将提取随机workspaceId，并将其放入${workspaceId}变量中。
查询项目
最后，我们需要根据之前提取的项目来查询workspaceId。为此，我复制并修改了之前的请求以获得一些时间。
使用workspaceId变量查询项目
这里我们设置了一个HTTP请求来查询工作区的项目：
- Http方法：必须是GET请求，不涉及参数，
- Http Scheme：
https由于我们的Rest API 由SSL保护， - 主机名：
api.octoperf.com， - 路径：
/design/projects/by-workspace/${workspaceId}/DESIGN。DESIGN工作空间中包含的项目的状态。（而不是结果，这将是RESULT）
我想我们已经准备好进行快速迭代来试试这个了！
查看结果
执行导致查询项目
如果我们多次执行用户，我们会看到响应因提取的随机workspaceId 而异。
最后的话
JMeter非常适合Rest API测试，特别是那些基于Json格式的测试。使用JMeter测试Json API非常简单。
基本上，如果你掌握了上面提到的JMeter组件，那么你很高兴！
如果你想进一步挖掘，我强烈建议你阅读我们的文章：
- JMeter JsonPath Extractor：从Json响应中提取任何内容，了解有关JsonPath语法的更多信息，
- JMeter Json Assertion：专门断言json响应，
- 和JMeter的插件，如Json的格式化可以使您的生活很多容易通过格式化输出。