何时需要权衡可见性

何时需要权衡可见性

本节讨论了一些可能需要对可见性做出权衡的常见场合。

问题描述

您想知道有哪些常见场合可能需要让请求和响应降低对协议的可见性。

解决方案

当有多个共享数据的资源，或一个操作总是要修改多个资源时，请考虑降低可见性，以得到更好的信息抽象、更松散的耦合程度、更好的网络效率、更好的资源粒度，或者纯粹为了方便客户端使用。

问题讨论

可见性经常与其他架构要求相冲突，如抽象、松耦合、效率和信息粒度等。例如，考虑一个“人”资源与一个相关的“地址”资源，任何客户端都可以提交一个GET请求得到这两个资源的表述，但为了方便客户端，服务器端可能会在“人”的资源表述中包含“地址”资源，就像下面这样：

# 获取“人”的请求

GET /person/1 HTTP/1.1

Host:

Content-Type: application/xml;charset=UTF-8

John Doe

1 Main Street

Bellevue

WA

# 获取地址的请求

GET /person/1/address HTTP/1.1

Host:

Content-Type: application/xml;charset=UTF-8

1 Main Street

Bellevue

WA

让我们假设服务器允许客户端提交PUT请求更新这些资源。当一个客户端修改了其中一个资源，相关资源的状态也会改变。然而，在HTTP 层面上，这些是相互独立的资源。只有服务器才知道它们是相互依赖的。数据的重叠是降低可见性的常见原因。

降低可见性的重要影响之一是缓存（详见第9 章）。由于这些资源在HTTP 层面上是相互独立的，缓存将有两个“地址”的副本：一个独立的“地址”表述，以及作为“人”的一部分的表述，这样是很低效的。而且，在缓存中一个表述失效不会影响另一个表述，这样一来陈旧的表述就保留在缓存里了。

在这个例子中，您可以包含一个指向地址的引用，以此避免包含详细地址，从而消除这些资源之间的重叠。可以使用链接（详见第5 章）向其他资源提供引用。

尽管提供链接可以减少数据重叠，但这将迫使客户端发起更多的请求。

在这个例子中，可见性和客户端的易用性之间需要权衡，也许还包括网络效率。一个需要“人”资源的客户端可以通过单个请求得到“人”及“地址”的信息。

下面这些情况下，您可能需要为了其他好处放弃可见性：

方便客户端

为了方便客户端使用，服务器可能需要设计特定目标的粗粒度组件资源

抽象

为了抽象复杂的业务操作（包括事务），服务器可能需要使用控制器资源来改变其他资源（例如，2.6 节）。这样的资源可以隐藏业务操作的实现细节。

网络效率

当客户端需要在短时间内连续执行几个操作时，可能需要将这些操作组合到一个批处理中，以降低网络延迟。

这些情况中，如果只关注可见性，您的Web 服务就不得不设计成以无重叠的独立资

源形式来显示所有数据。按这种方式设计的Web 服务，可能导致资源粒度过细，客

户端和服务器之间分离关注点不够，可详见2.6 节中的例子。其他场合包括复制或

合并资源、部分更新，可能也需要权衡可见性。

 

本文节选自《RESTful Web Services Cookbook中文版 》一书

图书详细信息:http://blog.chinaunix.net/space.php?uid=13164110&do=blog&id=2920780