网络服务相关技术解析
1. APP 相关资源介绍
1.1 服务文档
APP 对服务文档提及较少,仅规定了其表示格式,并要求在接收到 GET 请求时提供表示。但未说明服务文档最初是如何上传到服务器的。开发 APP 应用时,可提前硬编码服务文档,也可通过向 APP 未涵盖的新资源发送 POST 请求来创建新文档。还能将其作为静态文件公开,或使其响应 PUT 和 DELETE 请求。
1.2 类别文档
APP 成员可被分类。类别文档列出了特定 APP 集合的类别词汇,其媒体类型为
application/atomcat+xml
。以下是一个类别文档的示例:
<?xml version="1.0" ?>
<app:categories
xmlns:app="http://purl.org/atom/app#"
xmlns="http://www.w3.org/2005/Atom"
scheme="http://www.example.com/categories/RestfulNews"
fixed="no">
<category term="local" label="Local news"/>
<category term="international" label="International news"/>
<category term="lighterside" label="The lighter side of REST"/>
</app:categories>
该方案不固定,意味着即使成员属于文档中未列出的类别,也可发布到集合中。APP 仅定义了类别文档的表示格式和 GET 操作,创建、修改和删除操作需自行定义。
1.3 二进制文档作为 APP 成员
客户端向 APP 集合发送二进制文档(如图片)时,资源会有两种表示:二进制文件和包含元数据的 XML 文档(Atom 条目)。以下是一个上传 JPEG 文件的示例:
POST /leonardr/photos HTTP/1.1
Host: www.example.com
Content-type: image/jpeg
Content-length: 62811
Slug: A picture of my guinea pig
[JPEG file goes here]
服务器响应如下:
201 Created
Location: http://www.example.com/leonardr/photos/my-guinea-pig.atom
URI 指向的是描述并链接到该文件的 Atom 条目文档:
<![CDATA[ <?xml version="1.0" encoding="utf-8"?>
<entry>
<title>A picture of my guinea pig</title>
<updated>2007-01-24T11:52:29Z</updated>
<id>urn:f1ef2e50-8ec8-0129-b1a7-003065546f18</id>
<summary></summary>
<link rel="edit-media" type="image/jpeg"
href="http://www.example.com/leonardr/photos/my-guinea-pig.jpg" />
</entry>
资源状态的其他元素包括标题、摘要、最后更新时间、图像表示的 URI 和唯一 ID。可对元数据文档进行修改并发送 PUT 请求,也可发送 DELETE 请求删除成员。
1.4 APP 资源及方法总结
| 资源 | GET | POST | PUT | DELETE |
|---|---|---|---|---|
| 服务文档 | 返回表示(XML) | 未定义 | 未定义 | 未定义 |
| 类别文档 | 返回表示(XML) | 未定义 | 未定义 | 未定义 |
| 集合 | 返回表示(Atom 提要) | 创建新成员 | 未定义 | 未定义 |
| 成员 | 返回此 URI 标识的表示(通常是 Atom 条目文档,也可能是二进制文件) | 未定义 | 更新此 URI 标识的表示 | 删除成员 |
2. GData 扩展
2.1 集合查询
GData 引入了新的资源类型:搜索结果列表。它能对 APP 集合进行各种切片,提供了更多搜索可能性。例如:
-
http://www.example.com/RestfulNews?q=stadium
:内容包含“stadium”一词的成员子集合。
-
http://www.example.com/RestfulNews/-/local
:分类为“local”的成员子集合。
-
http://www.example.com/RestfulNews?author=Tom%20Servo&max-results=50
:作者为“Tom Servo”的最多 50 个成员。
搜索结果通常以 Atom 提要表示,包含匹配查询的成员条目元素以及 OpenSearch 元素,用于指定匹配查询的成员数量和每页显示的成员数量。
2.2 数据扩展
GData 在其“gd”命名空间中定义了许多新的 XML 实体,用于表示 Google 网络服务的特定领域数据。以 Google 日历服务为例,事件除了具有典型的 Atom 字段外,还包含特定的日历数据,如事件发生时间、地点、是否重复等。Google 日历的 GData API 使用
gd:when
、
gd:who
和
gd:recurrence
等标签将这些数据放入 Atom 提要中。
3. POST Once Exactly(POE)
3.1 问题提出
POST 请求在可靠 HTTP 中是个问题,因为它可能产生不同的副作用,多次发送可能导致不同结果。而 GET、PUT 和 DELETE 请求可在首次未成功时重新发送。
3.2 POE 解决方案
POE 使 HTTP POST 具有幂等性。如果资源支持 POE,它在整个生命周期内仅会成功响应一次 POST 请求,后续请求将返回 405(“Method Not Allowed”)。以下是实现步骤:
1. 客户端向“weblog”资源发送 GET 或 HEAD 请求,并包含特殊的 POE 头:
HEAD /weblogs/myweblog HTTP/1.1
Host: www.example.com
POE: 1
- 服务器响应包含一个尚未接收过 POST 请求的 POE 资源的 URI:
200 OK
POE-Links: /weblogs/myweblog/entry-factory-104a4ed
- 客户端向该 URI 发送新博客条目的表示。POST 成功后,该 URI 将不再接受 POST 请求。
3.3 替代方案
可让客户端生成自己的唯一 ID 并使用 PUT 代替 POST,从而避免使用 POST 并获得 POE 的好处,但需确保两个客户端不会生成相同的 ID。
4. 超媒体技术
4.1 超媒体类型
超媒体有两种类型:链接和表单。链接是当前资源与目标资源之间的连接,JSON 和纯文本也可看作超媒体格式。
4.2 表单类型
- 应用表单 :展示如何操作应用状态,可处理名称遵循特定模式的资源,使一个资源能链接到无限数量的其他资源。例如搜索引擎的搜索表单,用户输入查询后,浏览器构造 URI 并发送 GET 请求。
- 资源表单 :展示如何格式化修改资源状态的表示,用于 POST 和 PUT 请求。
4.3 超媒体的作用
链接和应用表单实现了连通性,即“超媒体作为应用状态的引擎”。客户端控制应用状态,服务器可通过发送链接和表单建议可能的下一个状态。而资源表单是更改资源状态的指南,资源状态最终由服务器维护。
下面是一个简单的 mermaid 流程图,展示了 POE 的工作流程:
graph LR
A[客户端] -->|GET/HEAD 请求 + POE 头| B[服务器]
B -->|返回 POE 资源 URI| A
A -->|POST 新条目| C[POE 资源]
C -->|首次 POST 成功| D[资源状态更新]
A -->|再次 POST| C
C -->|返回 405| A
综上所述,APP 是处理常见 Web 服务问题的有效方式,GData 对其进行了扩展,POE 解决了 POST 请求的幂等性问题,超媒体技术则增强了资源之间的连通性。这些技术在不同场景下发挥着重要作用,为 Web 服务的开发和使用提供了便利。
5. 技术应用场景与优势分析
5.1 应用场景
- 新闻资讯平台 :可使用 APP 来管理新闻文章的发布和分类。通过服务文档组织不同的新闻集合,如国内新闻、国际新闻等;利用类别文档对新闻进行分类标签,方便用户筛选查看。GData 的集合查询功能可用于实现新闻的搜索,如按关键词、作者等进行搜索。
- 图片分享网站 :对于图片上传和管理,APP 处理图片作为二进制文档的上传和元数据管理。用户上传图片时,服务器生成对应的 Atom 条目文档,包含图片的标题、摘要等信息。GData 可用于对图片进行分类搜索,如按主题、拍摄时间等。
- 日历应用 :Google 日历服务利用 GData 的数据扩展,将日历特定的数据(如事件时间、地点、重复规则等)融入 Atom 提要中。用户可以通过 APP 规范创建、修改和删除日历事件。
5.2 优势分析
| 技术 | 优势 |
|---|---|
| APP |
- 提供了处理列表/提要/集合的标准方式,减少开发工作量。
- 有现有的客户端支持,便于集成。 |
| GData |
- 扩展了 APP 的功能,增加了搜索和特定领域数据表示的能力。
- 多个 Google 服务采用相同接口,便于统一开发和使用。 |
| POE |
- 解决了 POST 请求的幂等性问题,提高了 HTTP 请求的可靠性。
- 即使 POST 操作违反资源导向架构,也能保证请求的可靠性。 |
| 超媒体技术 |
- 增强了资源之间的连通性,使客户端能够根据服务器提供的链接和表单进行操作。
- 服务器可引导客户端进入不同的应用状态,提高用户体验。 |
6. 技术操作流程总结
6.1 APP 资源操作流程
graph LR
A[客户端] -->|GET| B[服务文档]
A -->|GET| C[类别文档]
A -->|GET| D[集合]
A -->|POST| D
A -->|GET| E[成员]
A -->|PUT| E
A -->|DELETE| E
- 服务文档 :客户端发送 GET 请求获取服务文档的 XML 表示。
- 类别文档 :客户端发送 GET 请求获取类别文档的 XML 表示。
- 集合 :客户端发送 GET 请求获取集合的 Atom 提要;发送 POST 请求创建新成员。
- 成员 :客户端发送 GET 请求获取成员的表示;发送 PUT 请求更新成员表示;发送 DELETE 请求删除成员。
6.2 GData 操作流程
- 集合查询 :客户端构造包含查询参数的 URI 发送 GET 请求,服务器返回匹配的搜索结果(Atom 提要)。
- 数据扩展 :客户端根据不同的 Google 服务,解析包含特定领域数据的 Atom 提要。
6.3 POE 操作流程
- 客户端发送 GET 或 HEAD 请求到资源,并包含 POE 头。
- 服务器返回 POE 资源的 URI。
- 客户端向 POE 资源发送 POST 请求。
- 首次 POST 成功后,后续 POST 请求返回 405。
6.4 超媒体操作流程
- 应用表单 :客户端在应用表单中输入信息,浏览器构造 URI 并发送 GET 请求。
- 资源表单 :客户端根据资源表单的要求,格式化 POST 或 PUT 请求的表示。
7. 技术对比与选择建议
7.1 技术对比
| 技术 | 功能特点 | 适用场景 |
|---|---|---|
| APP | 处理常见 Web 服务的列表/提要/集合问题,定义了基本资源和操作。 | 简单的内容发布和管理系统,如博客、新闻网站等。 |
| GData | 在 APP 基础上扩展了搜索和特定领域数据表示功能。 | 需要复杂搜索和特定数据处理的 Google 相关服务或类似应用。 |
| POE | 解决 POST 请求的幂等性问题。 | 对 POST 请求可靠性要求较高的场景,如支付系统、订单处理等。 |
| 超媒体技术 | 增强资源之间的连通性,引导客户端操作。 | 需要良好用户交互和资源导航的 Web 应用。 |
7.2 选择建议
- 如果是简单的内容发布系统,可优先选择 APP,利用其标准的资源管理方式。
- 若涉及 Google 服务或需要复杂的搜索功能,GData 是更好的选择。
- 对于对 POST 请求可靠性要求高的场景,应考虑使用 POE。
- 注重用户交互和资源导航的应用,可采用超媒体技术来提升用户体验。
总之,这些网络服务相关技术各有特点和优势,开发者应根据具体的应用场景和需求,合理选择和组合使用这些技术,以实现高效、可靠和易用的 Web 服务。
超级会员免费看

被折叠的 条评论
为什么被折叠?



