api - REST 复杂/复合/嵌套资源

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

2年前关闭。



Improve this question




我正在尝试围绕解决基于 REST 的 API 中的概念的最佳方法。不包含其他资源的平面资源没有问题。我遇到麻烦的地方是复杂的资源。

例如，我有一本漫画书的资源。 ComicBook上面有各种属性，比如 author , issue number , date等

一本漫画书也有一个列表1..n覆盖。这些封面是复杂的对象。它们包含许多关于封面的信息:艺术家、日期，甚至是封面的 Base 64 编码图像。

对于 GET在 ComicBook我可以退回漫画，以及所有封面，包括他们的 base64 图像。对于获得一部漫画来说，这可能不是什么大问题。但是假设我正在构建一个客户端应用程序，它想要在一个表中列出系统中的所有漫画。
该表将包含来自 ComicBook 的一些属性。资源，但我们当然不想显示表格中的所有封面。返回 1000 本漫画书，每本漫画书都有多个封面，这将导致大量数据通过网络传输，在这种情况下，最终用户不需要这些数据。

我的直觉是做Cover一个资源并拥有 ComicBook包含封面。所以现在Cover是一个 URI。 GET现在的漫画作品，而不是巨大的 Cover我们为每个封面发回一个 URI，客户可以根据需要检索封面资源。

现在我在创作新漫画时遇到了问题。当然，当我创建 Comic 时，我至少要创建一个封面。 ，实际上这可能是商业规则。
所以现在我被困住了，我要么通过首先提交 Cover 来强制客户执行业务规则。 ，获取该封面的 URI，然后 POST正在ComicBook在列表中使用该 URI，或者我的 POST在 ComicBook接收与吐出不同的资源。 POST 的传入资源和 GET都是深拷贝，其中传出GET s 包含对依赖资源的引用。
Cover资源在任何情况下都可能是必要的，因为我确定作为客户，我希望在某些情况下解决封面方向。所以无论依赖资源的大小如何，问题都以一般形式存在。一般来说，您如何处理复杂的资源而不强制客户端“知道”这些资源是如何组成的？

Answer 1

@ray，很好的讨论

@jgerman，不要忘记，仅仅因为它是 REST，并不意味着资源必须从 POST 开始。

您选择在资源的任何给定表示中包含什么取决于您。

您单独引用封面的情况仅仅是创建父资源(漫画书)，其子资源(封面)可能会被交叉引用。例如，您可能还希望分别提供对作者、出版商、人物或类别的引用。您可能希望单独或在将它们作为子资源引用的漫画书之前创建这些资源。或者，您可能希望在创建父资源时创建新的子资源。

您对封面的具体情况稍微复杂一些，因为封面确实需要一本漫画书，反之亦然。

但是，如果您将电子邮件消息视为资源，而将发件人地址视为子资源，则显然仍然可以单独引用发件人地址。例如，从地址中获取所有内容。或者，使用以前的发件人地址创建新邮件。如果电子邮件是 REST，您可以很容易地看到许多交叉引用的资源可用:/received-messages、/draft-messages、/from-addresses、/to-addresses、/addresses、/subjects、/attachments、/folders 、/tags、/categories、/labels 等。

本教程提供了一个很好的交叉引用资源示例。
http://www.peej.co.uk/articles/restfully-delicious.html

这是自动生成数据的最常见模式。例如，您不要发布新资源的 URI、ID 或创建日期，因为这些是由服务器生成的。然而，当您取回新资源时，您可以检索 URI、ID 或创建日期。

您的二进制数据示例。例如，您希望将二进制数据作为子资源发布。当您获得父资源时，您可以将这些子资源表示为相同的二进制数据，或者表示为表示二进制数据的 URI。

表单和参数已经不同于资源的 HTML 表示。发布导致 URL 的二进制/文件参数并不是一件容易的事。

当您获取新资源的表单 (/comic-books/new) 或获取编辑资源的表单 (/comic-books/0/edit) 时，您需要的是资源的特定于表单的表示形式。如果您使用内容类型“application/x-www-form-urlencoded”或“multipart/form-data”将其发布到资源集合，则您要求服务器保存该类型表示。服务器可以使用已保存的 HTML 表示或其他形式进行响应。

出于 API 或类似目的，您可能还希望允许将 HTML、XML 或 JSON 表示发布到资源集合。

也可以按照您的描述来表示您的资源和工作流程，考虑到在漫画书之后发布的封面，但要求漫画书有封面。示例如下。

允许延迟创建封面

允许创建带有所需封面的漫画书

允许交叉引用封面

允许多个封面

创建漫画书草稿

创建漫画书封面草稿

出版漫画草稿

获取/漫画书
=> 200 OK，获取所有漫画书。

获取/漫画书/0
=> 200 OK, 获取带有封面 (/covers/1,/covers/2) 的漫画书 (id: 0)。

获取/comic-books/0/covers
=> 200 OK，获取漫画书的封面(id:0)。

获取/封面
=> 200 OK，获取所有封面。

获取/封面/1
=> 200 OK，用漫画书 (/comic-books/0) 获取封面 (id: 1)。

获取/漫画书/新
=> 200 OK，获取创建漫画书的表单(表单:POST/draft-comic-books)。

POST/draft-comic-books
标题=foo
作者=嘘
出版商=goo
已发布=2011-01-01
=> 302 Found，位置:/draft-comic-books/3，重定向到带有封面(二进制)的草稿漫画书(id:3)。

获取/draft-comic-books/3
=> 200 OK，获取带有封面的漫画书草稿(ID:3)。

获取/draft-comic-books/3/covers
=> 200 OK，获取草稿漫画书的封面(/draft-comic-book/3)。

获取/draft-comic-books/3/covers/new
=> 200 OK，获取为草稿漫画书创建封面的表单(/draft-comic-book/3)(表单:POST/draft-comic-books/3/covers)。

POST/draft-comic-books/3/covers
封面类型=正面
封面数据=(二进制)
=> 302 发现，位置:/draft-comic-books/3/covers，重定向到草稿漫画书的新封面(/draft-comic-book/3/covers/1)。

获取/draft-comic-books/3/publish
=> 200 OK，获取发布漫画草稿的表单(id:3)(表单:POST/published-comic-books)。

POST/published-comic-books
标题=foo
作者=嘘
出版商=goo
已发布=2011-01-01
封面类型=正面
封面数据=(二进制)
=> 302 Found, Location:/comic-books/3, 重定向到已出版的漫画书 (id: 3) 和封面。