标签：
这个简短的教程将指导您完成架构推理功能。
我们首先创建一个新项目,并添加一个没有一个初始WADL文件的REST服务。
发送请求后,我们就可以使用反应进行构建。
我们将演示 Flickr其他例子 。
请求(成功)返回一个响应这种格式:
<rsp stat="ok">
<method>flickr.test.echo</method>
<format>rest</format>
<foo>bar</foo>
<api_key>9e5f204388e9d6070b6b1423876be728</api_key>
</rsp>
注意: 的 API 关键变化,所以你可能需要访问 Flickr其他演示网站 并得到一个日期 API 键。
获得请求到REST项目很容易:
的 创建其他项目 窗口打开:
项目被创建并添加到工作区:
从请求的 URL 自动提取参数,并显示在表单编辑器。
现在我们有一个请求处理:
已经填充的参数使用默认值。
我们还没有发送请求,响应是空白:
响应视图选项卡底部称为“架构”。 这是一个 推断架构检查器 。
没有信息记录。
通常,我们想要解决架构冲突的过程自动化的流程。 但出于演示目的,我们将手动进行:
请求被发送,我们会有回应:
注意: 的 API 关键变化,所以你可能需要访问 Flickr其他演示网站 并得到一个日期 API 键。
Schema选项卡更改显示冲突架构:
这意味着响应的分析表明,当前响应和前面推断架构之间有冲突。 在这种情况下,这都是应该的,因为不存在预先的架构。
我们现在可以手动解决冲突。
对于每个检测到冲突,我们会得到一个通知,可以根据需要采取行动。
在这种情况下,我们可以假定所有的冲突都应该得到解决(再一次,没有以前的架构)。
所有的冲突都将自动解决,和登录日志的架构:
当所有冲突已经解决,架构的架构添加选项卡:
到目前为止,我们可以看到一个名称空间,和相关的XSD架构。 作为这种架构是基于只有一个响应,我们可以完善它,用更多的请求。 同时我们应该试着改变反应使它们尽可能不同。 例如,我们可以发出一个无效的请求,我们可以推断出故障的架构,或请求一个查询,它返回一个空结果集,等等。
更多的反应可以被添加到自动架构,只需发送另一个请求。 因为我们可以假定反应将是有效的,我们可以使用“Auto-Resolve”功能。
得到不同的响应,我们需要改变的要求:
api_key 价值这将确保我们得到一个错误响应。
请求被发送,我们会有回应:
这一次,发生冲突解决和自动记录:
当所有冲突已经解决,新的反应架构中包含的架构选项卡:
新的反应架构中包括:
| 之前 | 后 |
|---|---|
 |
 |
当一个架构被推断 在响应窗口选项卡它是可用的 架构:
架构也可以被添加到服务接口和成为你服务定义的一部分。
定义视图可以在接口级别项目:
WADL内容选项卡显示当前的定义:
选项卡列出可用的内容 资源 , 方法 , 表示 ,WADL内容:
重建WADL推断架构作为一个单独的选项卡中添加内容窗口:
的资源、方法和表示被添加到列表中,和架构内容显示在对应的选项卡:
推断架构像手动创建的一样的可以使用。 这意味着您可以使用断言验证您的响应。 你可以一起将它们导出生成的WADL布局,或使用代码生成工具。 您也可以使用它们来生成 HTML 文档为你服务。
标签：
原文地址：http://www.cnblogs.com/zerotest/p/4690952.html
