这份简短的教程将引导您完成架构推断功能。

我们将创建一个新的项目，并添加一个REST服务，而初始WADL文件启动了。

发送请求后，我们就可以使用响应来构建我们的架构。

为了演示的原则，我们会从一个演示Flickr的REST的例子。

https://www.flickr.com/services/rest/?method=flickr.test.echo&format=rest&foo=bar&api_key=d6c7b624b138bcb07a2e2c736aefeb65

该请求（成功时）返回以下这种格式的响应：

<rsp stat="ok">
    <method>flickr.test.echo</method>
    <format>rest</format>
    <foo>bar</foo>
    <api_key>9e5f204388e9d6070b6b1423876be728</api_key>
</rsp>

获取很容易请求到一个REST项目：

• 打开文件菜单
• 选择新的REST项目

在创建REST项目窗口打开：

• 复制和以往的网址进入该区域

• 点击确定

该项目被创建并添加到工作区：

来自请求的参数的URL被自动提取，并可以在编辑器中查看。

现在我们发起请求：

该请求包含所有在它定义的参数。参数已经使用默认值预先填充。

我们还没有发送的请求，所以响应是空白：

其余的反应来看具有所谓的“架构”底部的标签。这是推断架构检查员。

• 打开架构选项卡

没有信息已被尚未登陆。

一般情况下，我们希望解决方案的冲突的过程自动化。但出于演示的目的，这个时候我们将采取手动：

• 确保自动解析被禁用。

• 点击运行 

该请求被发送，并且我们获得回应：

注：该API的主要变化，所以你可能需要访问Flickr的REST演示站点，并得到一个最新的API密钥。

架构选项卡发生变化，表明架构的冲突时有发生：

这意味着该反应的分析表明，有当前响应和先前推断模式之间的冲突。

• 打开架构检查

现在，我们可以手动解决冲突。

• 点击解决冲突

对于每个检测到冲突时，我们会得到一个通知，并可以根据需要采取行动。

在这种情况下，我们可以假设所有冲突应该解决（再次，没有以前的模式）。

• 点击Yes（是）所有 *

所有冲突，然后自动解决，并记录在日志模式：

当所有的冲突已经解决，该架构被添加在架构选项卡：

到目前为止，我们可以看到一个命名空间，并为关联了XSD架构。作为根据仅一个响应的架构，我们可以通过一些更多的请求优化它。我们应该尝试改变响应，使他们尽可能不同。例如，我们可以发出一个无效的请求，这样我们就可以推断架构故障，或使该返回一个空的结果集的查询请求，等等。

更多的反应，可以自动添加到架构，通过简单的发送不同的请求。既然我们可以假设反应将是有效的，我们可以用“Auto-Resolve”功能。

• 返回到冲突标签

• 确保自动解决启用。

为了得到不同的回应，我们需要改变的要求：

• 删除API_KEY值

这将确保我们得到一个错误响应。

• 点击运行 

该请求被发送，并且我们获得回应：

这一次，因为发生冲突得以解决，并自动记录：

当所有的冲突都解决了，新的响应被包含在架构选项卡中：

新的响应已被列入架构：

前	后

现在，您可以继续修改要求，并建立起自己的模式。