5

您将如何对可以具有两种不同表示的资源进行建模。例如，一种表示可能是“瘦的”，其大部分相关资源可通过链接访问。另一种表示可能是“胖”的，其中嵌入了大多数相关资源。这个想法是，一些客户不介意必须多次调用来浏览链接的资源，但其他客户希望一次获得所有数据。

考虑一个与导演、演员等相关联的电影资源。也许它的精简版本只有电影标题，并且要获取导演的数据、演员列表等，必须通过嵌入它们的链接。也许它的胖版本包含嵌套在里面的所有电影，包括导演的数据，各种演员的数据等。

应该如何建模？

我看到几个选项：

  1. 这两种表示实际上是两种不同的资源，需要不同的 URI
  2. 这两种表示实际上是相同的资源，您可以通过自定义媒体类型在两种表示之间进行选择，例如application/vnd.movie.thin+json和application/vnd.movie.fat+json。
  3. 这两种表示实际上是相同的资源，应该使用查询参数（例如/movies/1?view=thin）来选择不同的表示。
  4. 还有什么...

您认为这种 API 的正确方法是什么？

4

3 回答 3

6

您可以将prefer 标头与 return-minimal 参数一起使用。

于 2014-06-20T04:07:29.190 回答
2

我更喜欢为此使用 Content-Type。您也可以使用参数：

application/vnd.myapp; profile=light

于 2014-05-17T02:08:35.730 回答
1

关于 REST的Fielding 论文告诉您资源接口，您必须将 IRI 绑定到资源，这些资源是实体集。（这与 SOAP 不同，因为在那里您通常将 IRI 绑定到操作。）

根据Darrel Miller的说法，路径用于描述分层数据，查询字符串用于描述 IRI 中的非分层数据，但我们将路径和查询一起用于识别 API 内的资源。

因此，基于这些，您有两种方法：

  • 您可以说，具有较少属性的同一实体可以映射到具有自己的 IRI 的新资源。在这种情况下 the/movies/1?view=thin或 the/movies/1/view:thin是可以的。
    优点：
  • 根据 RDF，属性具有或两者rdf:type之一，而 REST 具有与语义网络和链接数据的连接。rdf:Propertyrdfs:Resource
  • 例如，为单个属性创建 IRI 是一种常见的做法/movies/1/title，因此，如果我们可以通过单个属性执行此操作，那么我们也可以通过属性集合来执行此操作。
  • 它类似于我们已经用于实体集合的map reduce/movies/recent ：等等......唯一的区别是，我们通过实体集合来减少列表或有序集，而通过属性集合我们可以减少地图。将两者结合使用会更有趣，例如：/movies/recent/title，它可以返回最近电影的标题。

缺点：

  • 通过 RDF，一切都有一个rdf:type，rdfs:Resource也许 REST 不遵循 Web 文档的相同原则。

  • 我还没有发现任何关于单个属性或属性集合可以或不能被视为论文中的资源的信息，但是我可能不小心跳过了文本的那一部分（相当枯燥的东西）......

  • 您可以说具有较少属性的同一实体只是同一资源的不同表示，因此它不应该具有不同的 IRI。在这种情况下，您必须将有关首选视图的数据放入请求中的其他位置。由于 GET 请求没有正文，而且 HTTP 方法不用于存储此类内容，因此您可以放置​​的唯一位置是 HTTP 标头。通过长期的用户特定设置，您可以将其存储在服务器上，或者存储在客户端维护的 cookie 中。通过短期设置，您可以在许多标题中发送它。通过content-type标题，您可以定义自己的 MIME 类型，不推荐这样做，因为我们不喜欢可能仅由单个应用程序使用的数百个自定义 MIME 类型。通过content-type标题，您可以添加配置文件按照Doug Moscrop 的建议添加到您的 MIME 类型。通过prefer标题，您可以使用Darrel Miller建议的return-minimal设置。理论上你可以通过标题做同样的事情，但我只通过分页遇到了范围标题。 优点：range

  • 这当然是一种 RESTful 方法。

缺点：

  • 现有的 HTTP 框架并不总是支持提取此类标头参数，因此您必须编写自己的短代码来执行此操作。
  • 我找不到有关这些标头如何影响客户端和服务器端缓存机制的任何信息，因此某些浏览器可能不支持其中一些，并且服务器必须编写自己的缓存实现，或者找到支持标头的框架你想用。

注意：我个人更喜欢使用第一种方法，但这只是一种意见。

根据Darrel Miller的说法，IRI 的命名并不能真正计入 REST。

您只需确保单个 IRI 始终指向相同的资源，仅此而已。IRI 的结构不计入客户端，因为如果您不希望它因 IRI 命名的任何更改而中断，您的客户端必须满足 HATEOAS 约束。这意味着，服务器始终构建 IRI，客户端遵循这些 IRI，它在超媒体响应中获得。这就像使用网络浏览器来跟踪链接，然后浏览网络......通过 REST，您可以向您的超媒体添加一些语义，向您的客户解释它刚刚获得的内容。这可以是一些 RDF 词汇，例如 schema.org、微数据、iana 链接关系等等（甚至是您自己的应用程序特定词汇）......
所以使用漂亮的 IRI 不是 REST 关心的问题，只有在服务器端配置路由才是一个问题。您必须通过 REST IRI 确保您拥有资源 - IRI 映射而不是操作 - IRI 映射，并且您不使用 IRI 来维护客户端状态，例如存储用户 ID、凭据等...

于 2014-05-13T03:25:56.750 回答