REST推理
这份简短的教程将引导您完成架构推断功能。
我们将创建一个新的项目，并添加一个REST服务，而初始WADL文件启动了。
发送请求后，我们就可以使用响应来构建我们的架构。
演示请求
为了演示的原则，我们会从一个演示Flickr的REST的例子。
该请求（成功时）返回以下这种格式的响应：
<rsp stat="ok">
<method>flickr.test.echo</method>
<format>rest</format>
<foo>bar</foo>
<api_key>9e5f204388e9d6070b6b1423876be728</api_key>
</rsp>
注：该API的主要变化，所以你可能需要访问Flickr的REST演示站点，并得到一个最新的API密钥。
创建项目和服务
获取很容易请求到一个REST项目：
- 打开文件菜单
- 选择新的REST项目
在创建REST项目窗口打开：
- 复制和以往的网址进入该区域
- 点击确定
该项目被创建并添加到工作区：
来自请求的参数的URL被自动提取，并可以在编辑器中查看。
请求和响应
现在我们发起请求：
该请求包含所有在它定义的参数。参数已经使用默认值预先填充。
我们还没有发送的请求，所以响应是空白：
架构选项卡
其余的反应来看具有所谓的“架构”底部的标签。这是推断架构检查员。
- 打开架构选项卡
没有信息已被尚未登陆。
一般情况下，我们希望解决方案的冲突的过程自动化。但出于演示的目的，这个时候我们将采取手动：
- 确保自动解析被禁用。
获取响应
- 点击运行
该请求被发送，并且我们获得回应：
注：该API的主要变化，所以你可能需要访问Flickr的REST演示站点，并得到一个最新的API密钥。
架构选项卡发生变化，表明架构的冲突时有发生：
这意味着该反应的分析表明，有当前响应和先前推断模式之间的冲突。
- 打开架构检查
现在，我们可以手动解决冲突。
- 点击解决冲突
对于每个检测到冲突时，我们会得到一个通知，并可以根据需要采取行动。
在这种情况下，我们可以假设所有冲突应该解决（再次，没有以前的模式）。
- 点击Yes（是）所有 *
所有冲突，然后自动解决，并记录在日志模式：
推断架构
当所有的冲突已经解决，该架构被添加在架构选项卡：
到目前为止，我们可以看到一个命名空间，并为关联了XSD架构。作为根据仅一个响应的架构，我们可以通过一些更多的请求优化它。我们应该尝试改变响应，使他们尽可能不同。例如，我们可以发出一个无效的请求，这样我们就可以推断架构故障，或使该返回一个空的结果集的查询请求，等等。
添加定义
更多的反应，可以自动添加到架构，通过简单的发送不同的请求。既然我们可以假设反应将是有效的，我们可以用“Auto-Resolve”功能。
- 返回到冲突标签
- 确保自动解决启用。
不同的请求
为了得到不同的回应，我们需要改变的要求：
- 删除
API_KEY值
这将确保我们得到一个错误响应。
- 点击运行
该请求被发送，并且我们获得回应：
这一次，因为发生冲突得以解决，并自动记录：
更新模式
当所有的冲突都解决了，新的响应被包含在架构选项卡中：
新的响应已被列入架构：
| 前 | 后 |
|---|---|
 |
 |
现在，您可以继续修改要求，并建立起自己的模式。