36、网络服务相关技术解析

网络服务相关技术解析

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
  1. 服务器响应包含一个尚未接收过 POST 请求的 POE 资源的 URI:
200 OK
POE-Links: /weblogs/myweblog/entry-factory-104a4ed
  1. 客户端向该 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 服务。

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值