4

鉴于此服务可获取有关酒店的信息：

> GET /hotel/{id}

< HTTP/1.1 200 OK
< <hotel>
<   <a>aaa</a>
<   <b>aaa</b>
>   <biggie>aaa....I am 300K</biggie >
< </hotel>

问题是biggie300K，我们不想在每次响应时都返回它。什么是延迟加载这个值的 RESTful 方式？

我们是否应该设置两个资源：

> GET /hotel/{id}

< HTTP/1.1 200 OK
< <hotel>
<   <a>aaa</a>
<   <b>aaa</b>
< </hotel>

和..

> GET /hotel/{id}/biggie

< HTTP/1.1 200 OK
< <biggie>
<   <val>aaa....I am 300K</val>
< </biggie>

你只GET /hotel/{id}/biggie在你真正需要这些数据时才请求？

biggie这会起作用..虽然除了它是一个大数据集之外没有什么特别的。我认为将所有内容都保持在一个hotel级别会更好，因为所有属性实际上只是hotel.

4

3 回答 3

13

别忘了，超媒体是你的朋友。

GET /hotel/{id}

HTTP/1.1 200 OK
<hotel Id="99">
  <a>aaa</a>
  <b>aaa</b>
  <biggieLink href="/Hotel/99/Biggie"/>
</hotel>

或者你甚至可以做

GET /hotel/{id}

HTTP/1.1 200 OK
<hotel Id="99">
  <a>aaa</a>
  <b>aaa</b>
  <biggieSynopsis href="/Hotel/99/Biggie">
    <title>Here is a a summary of biggie</title>
  </biggieSynopsis
</hotel>
于 2009-10-26T17:30:52.320 回答
3

将其设置为两个资源会起作用，但如果您不喜欢这样，您可以考虑使用缓存；根据数据的性质，这实际上可能比拆分为多个资源节省更多的负载。

于 2009-10-26T17:13:45.177 回答
1

我认为你的解决方案很好。没有完美的答案，但三种可能性是：

  1. 每次发送所有属性
  2. 按要求单独发送属性 ( /{id}/a, /{id}/b, /{id}/biggie)
  3. 按照您的建议，发送所有属性，除了不寻常的属性。

1 和 2 很好，因为它们是统一的，但是 3 在您的情况下是有意义的，或者在一条数据需要登录凭据的情况下，例如。

（2 还有一个缺点是需要与请求者更紧密地耦合，请求者必须知道每个属性的名称。）

于 2009-10-26T17:18:31.800 回答