REST API 中“活动”资源的概念答案

【问题标题】：Concept of "active" resource in a REST APIREST API 中“活动”资源的概念
【发布时间】：2013-11-14 04:51:48
【问题描述】：

我正在开发一个可以将特定资源指定为“活动”的 REST API。为了说明，这是我想要实现的一个简单示例：

假设我有一个代表书籍集合的 URI：/books。

给定的图书具有/books/{id} 形式的规范URI。

我有另一个 URI，它提供指向活动书籍的指针：/books/active。这将简单地发送一个 HTTP 303 引用活动书籍的规范 URI。

让客户同时更新有效图书的最佳方式是什么？我是否应该允许客户在/books/active 上发出 PUT，指定活动书籍的规范 URI，还是有另一种普遍接受的模式来做这种事情？（对我来说，客户端会发出一个发送规范 URI 而不是资源的实际表示的 PUT 对我来说似乎很奇怪。）

更新： 一次只能激活一本书（互斥），所以我认为将激活标志作为图书本身的属性是没有意义的，因为那样会暗示不止一本书可以将值设置为 true。

【问题讨论】：

活跃是图书资源的属性吗？另外，是否有更高级别的资源包含书籍（如书架等）？
@bryanmac 我已经更新了我的问题以澄清活动的定义。而且，是的，在我的案例中还有一个更高级别的资源。我只是想让示例保持简单，但可以随意使用更高级别的资源作为答案的一部分。谢谢。
整个系统一次只能激活一本书？还是每个用户都这样？
我也不明白为什么使用规范 URI 发出 PUT 对您来说似乎很奇怪。使用 URI 作为资源 ID 内置于 GET 和 PUT 的定义中。

【解决方案1】：

通过允许PUT /books/active 之类的内容将状态构建到您的 URI 中是一个坏主意。它完全符合服务器提供足够缓存的能力，并且由 Tim Stokes 提供 called out as an anti-pattern。

RESTful 系统中的 URI 应该唯一地标识一个资源。虽然资源的表示可能会改变（并且资源的状态可能会改变），但绝不应该使用相同的 URI 来指向不同的资源。这样做违背了 GET 和 PUT 等方法的预期语义。

在您的情况下，仅在书籍集合中包含查询参数有什么问题？例如，GET /books?state=active。这将为您返回所有活动书籍的集合（可能始终是 1 本书，但如果将来发生变化怎么办？）您可以从那里向下钻取并 PUT 到规范 URI。

更好的是，建立一个链接关系架构，并在图书收藏的“self”链接旁边简单地包含一个“active-book”关系。这样你的客户甚至不需要知道你的 URL 约定；它可以简单地跟随服务器提供的链接。

【讨论】：

【解决方案2】：

如果您有一个包含书籍的更高级别的资源，那么它可以具有一个 activeBook 属性，其值为书籍 id 和/或活动书籍的完整 URL。例如，如果用户有一个书架，那么 /user/myShelf 就会有书，而我正在阅读的活动书籍将是我书架上的活动书籍。

这比在每本书上都有一个属性（如 isActive 或将状态放在 url 中）更优雅。

我们在其中一个公共 API 中遇到了类似的问题，因此采用了这种方法。如果没有清楚地了解所有资源及其关系，就很难确定。也许如果你再澄清一点关系......

【讨论】：