3

我们应该如何使用 REST 以高效的方式访问多维数据？选择似乎是 hi-REST、lo-REST 或 OpenSearch（这似乎是 lo-REST 的一种特殊化）。

4

2 回答 2

2

为了使您的系统成为 RESTful，其中一项要求是客户端事先不知道您的 URI 的结构。这意味着您不能像大多数 Twitter 客户端那样编写以特定方式构建 URI 的代码。传统观点是，为了定位资源，您需要在不同的位置发现它的 URI。

但是，有时您在系统中处理无数资源，并且提供指向每个资源的链接简直是愚蠢的。多维数据属于这一类。在这些情况下，为客户端提供 URI 构造规则是完全有效的，只要在运行时发现这些规则。

OpenSearch 绝对是这个问题的 RESTful 解决方案，而且它对程序员很友好。OpenSearch 的很多用途仅限于普通人类可读的 HTML 搜索结果，但实际上它也可以用于纯机器可读（例如 atom）的搜索结果：

<Url type="application/atom+xml"
     template="...search/?q={searchTerms}"/>

这个模板告诉客户如果你想要一个原子表示，你可以去这里。但这如何适合多维数据？OpenSearch 的可扩展性在这里发挥了作用。OpenSearch 时间扩展描述了如何指示客户端构建表示受限于特定时间范围的搜索的URL（假设xmlns:time绑定正确：

<Url type="application/atom+xml"
     template="...search/?after={time:start}&amp;before={time:end}"/>

如果客户端看到这个模板，它可以从模板中看到它只允许时间限制。让我们自己扩展它。

为了扩展 OpenSearch，我必须指定一个名称空间和该名称空间中的一些元素来表示特定的含义。这应该在某个地方发布，以便其他人可以访问文档并实现他们自己的服务器和客户端。假设您想按姓氏查找客户；姓氏是一个非常通用的术语，但还不够普遍，以至于它已被标准化。假设我定义了一个命名空间，将它绑定到name我的 OpenSearch 描述中的前缀，并公开以下模板：

<Url type="application/atom+xml"
     template="...search?lastName={name:last}"/>

此模板指示任何了解我的name命名空间的客户端，它可以通过填写模板进行姓氏查找。

这仍然不是多维的，但让我们添加另一个维度；地理。幸运的是，有一个用于地理的 OpenSearch 草稿扩展，它允许在边界框或圆圈内进行搜索：

<Url type="application/atom+xml"
     template="...search/?latitude={geo:lat?}&amp;
                          longitude={geo:lon?}&amp;
                          metres={geo:radius?}"/>

我正在拆分模板以使其可读。

该模板仍然不是多维的，因为它只允许在一维（地理空间）内进行搜索。那么如何进行多维搜索呢？您提供了一个模板，该模板展示了如何进行多维搜索，组合起来很有意义：

例如，这是一个模板，它允许我在不同的区域（二维）中找到具有给定姓氏的人：

<Url type="application/atom+xml"
     template="combo-find?customerLastName={name:last}&amp;
                          lat={geo:lat?}&amp;
                          lon={geo:lon?}&amp;
                          radius={geo:radius?}"/>

这是一个模板，它允许我限制名称和地理空间以及时间限制（尽管 OpenSearch Time 扩展没有说明您要查找的时间）：

<Url type="application/atom+xml"
     template="...search/?lastName={name:last}&amp;
                          lat={geo:lat?}&amp;
                          lon={geo:lon?}&amp;
                          r={geo:radius?}&amp;
                          after={time:start}&amp;
                          before={time:end}"/>

在这些示例中，客户端可以自由查看 URI 模板以确定要填写哪些 URI 模板参数。因此客户端会知道每个 URI 模板支持哪些维度，并且可以在任何时候找出最适合的 URI。

所有这一切的 RESTfulness 是因为所有的 REST 约束都得到了尊重。它是无状态的，超媒体是引擎，它是分层的，等等。OpenSearch 只是另一种超媒体格式，非常擅长！

于 2010-08-19T10:52:22.527 回答
0

根据我对术语 hi-REST 和 lo_REST 的 Google 搜索，我认为这两种选择都不会对效率产生太大影响。相反，这更多的是一个你想要“正确”到什么程度的问题。

Hi-REST 可以说更“正确”，但我怀疑使用 Hi-REST 是否会对效率产生重大影响。您选择传输数据的数据表示（即 XML、二进制 XML、JSON 等）将对数据性能产生更大的影响。

于 2010-08-18T23:03:28.360 回答