Question

我有一个包含项目列表的表示。这可能很容易包含几百个项目。

<List>
  <ListItem>...</ListItem>
  <ListItem>...</ListItem>
...
  <ListItem>...</ListItem>
  <ListItem>...</ListItem>
</List>

对于每个项目，我想提供一组可用的链接。在链接集中，每个项目可能只允许访问这些链接的子集，具体取决于某些条件。

以下示例演示了一种强制执行此操作的方法。

<List>
  <ListItem Id="345">
     <Link rel="foo" href="http://example.org/List/Items/345/foo"/>
     <Link rel="bar" href="http://example.org/List/Items/345/bar"/>
  </ListItem>
  <ListItem Id="346">
     <Link rel="bar" href="http://example.org/List/Items/346/bar"/>
  </ListItem>
  <ListItem Id="347">
     <Link rel="foo" href="http://example.org/List/Items/347/foo"/>
  </ListItem>

 ...
</List>

这是另一种方式

<List>
  <ListItem Id="345" AvailableRels="foo bar"/>
  <ListItem Id="346" AvailableRels="foo"/>
  <ListItem Id="347" AvailableRels="bar"/>
 ...
  <Link rel="foo" href="http://example.org/List/Items/{Id}/foo"/>
  <Link rel="bar" href="http://example.org/List/Items/{Id}/bar"/>
</List>

第二种方法看起来更清晰，它需要客户端更多的智能来处理URI模板。第二个显然小得多，通过网络传输，但是，我正在进行HTTP压缩，所以我真的应该关心吗？

思考？我还缺少其他问题吗？ AvailableRels的想法有点过于标准吗？在其他媒体类型中有类似的东西吗？

Answer 1

如果您只是想减小尺寸，请考虑在整个表示中包含一个“自我”链接（必须是绝对的），并在媒体类型或协议中声明所有相对链接都与它相关规范。（这就是Shoji的作用）然后你的例子缩小为：

<Link rel="self" href="http://example.org/List/Items/"/>
<List>
  <ListItem Id="345">
     <Link rel="foo" href="345/foo"/>
     <Link rel="bar" href="345/bar"/>
  </ListItem>
  <ListItem Id="346">
     <Link rel="bar" href="346/bar"/>
  </ListItem>
  <ListItem Id="347">
     <Link rel="foo" href="347/foo"/>
  </ListItem>

 ...
</List>

Answer 2

这些都是一些新的媒体类型，所以我想你可以定义这两种处理模型。自然的本能是与第一个本能一致，因为它不会在XML的一个区域中的属性和其他地方的URI模板之间添加不可见的耦合。

指导我们的现有技术将是例如atompub或sun cloud API，它们都暴露了大量的链接，经常重复。我只是想指出 OpenSearch 可以作为URI模板方法的证据，因为它公开了URI模板和特殊<Url>和{{1}元素名称与URI模板的大括号匹配的元素。我个人认为OpenSearch模板非常RESTful。纯HTML表单也可以做同样的事情，并且不能在其基本形式中被视为RESTful。

提供URI模板的缺点是你不能轻易地将一半的项目分区以使href进入服务器A，另一个进入服务器B，或者不同一半实际上有不同的地方。您实际上向您的客户端泄漏了一些关于底层数据结构的内容，因此客户端依赖于具有相同（ish）URI方案的所有项目来访问foo或bar，从而降低其灵活性（可能取决于您如何记录相关媒体类型）。

Answer 3

查看您的表示我发现与Atom Syndication Format非常惊人的相似，它使用atom：entry和atom：link来完成此操作。说实话，我对Atom Syndication Format（ASF）感到敬畏。

ASF的RFC http://tools.ietf.org/html/rfc4287

ASF中条目的分页 - rfc5005

如果使用RFC，您的Feed会显示为 -

   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://www.w3.org/2005/Atom">
     <title>Example Feed</title>
     <link href="http://example.org/" rel="self" />
     <link href="http://example.org/before/345" rel="next" type="application/atom+xml" />
     <link href="http://example.org/after/987" rel="previous" type="application/atom+xml"/>
     <updated>2003-12-13T18:30:02Z</updated>
     <author>
       <name>Darrel Miller</name>
     </author>
     <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

     <entry>
       <title>Item 987</title>
       <link href="http://example.org/List/Items/987/foo" rel="foo" />
       <link href="http://example.org/List/Items/987/bar" rel="bar" />
       <id>987</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text.</summary>
     </entry>
     ...
     <entry>
       <title>Item 345</title>
       <link href="http://example.org/List/Items/345/foo" rel="foo" />
       <id>345</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text.</summary>
     </entry>

   </feed>

我建议使用它来为客户端提供权力，以利用标准客户端来消耗您的表示。我个人更喜欢按照ASF上面提到的mogsie的分页。一旦分页到位，我会建议使用标准的HTTP来提高性能：

在响应中设置与HTTP缓存相关的标头，以便客户端可以使用它们来缓存响应
在Application Server前面使用缓存服务器（Squid，Varnish）来减少每次生成Feed。
支持压缩，即根据客户端功能支持普通和压缩内容。

Answer 4

如果你担心原始资源的大小，那么仅仅引入分页呢？

<List>
  <Previous href="http://example.org/List/before/345"/>
  <Next href="http://example.org/List/after/987"/>
  <ListItem Id="345">
     <Link rel="foo" href="http://example.org/List/Items/345/foo"/>
     <Link rel="bar" href="http://example.org/List/Items/345/bar"/>
  </ListItem>
  ...
  <ListItem Id="987"> ... </ListItem>
<List>

如何使用项目敏感链接创建超媒体列表？

4 个答案: