我正在开发一个可以将特定资源指定为“活动”的 REST API。为了说明，这是我想要实现的一个简单示例：
假设我有一个代表书籍集合的 URI /books：.
一本给定的书有一个规范的 URI 形式/books/{id}。
我有另一个 URI，它提供了指向活动书籍的指针：/books/active. 这将简单地发送一个 HTTP 303 引用活动书籍的规范 URI。
允许客户也更新活动书籍的最佳方式是什么？我应该允许客户在为活动书籍指定规范 URI 时发出 PUT /books/active，还是有另一种普遍接受的模式来做这种事情？（对我来说，客户端会发出一个发送规范 URI 而不是资源的实际表示的 PUT 对我来说似乎很奇怪。）
更新：一次只能激活一本书（互斥），所以我认为将活动标志作为书籍本身的属性是没有意义的，因为这意味着不止一本书可能具有价值设置为真。
如果您有一个包含书籍的更高级别的资源，那么它可以具有一个 activeBook 属性，其值为书籍 id 和/或活动书籍的完整 URL。例如，如果用户有一个书架，那么 /user/myShelf 就会有书，而我正在阅读的活动书籍将是我书架上的活动书籍。
这比在每本书上都有一个属性（如 isActive 或将状态放在 url 中）更优雅。
我们在我们的一个公共 API 中遇到了类似的问题，并采用了这条路线。如果没有清楚地了解所有资源及其关系，就很难确定。也许如果你再澄清一点关系......
通过允许类似PUT /books/active. 它完全破坏了服务器提供足够缓存的能力，并被 Tim Stokes称为反模式。
RESTful 系统中的 URI 应该唯一地标识一个资源。虽然资源的表示可能会改变（并且资源的状态可能会改变），但绝不应该使用相同的 URI 来指向不同的资源。这样做违背了 GET 和 PUT 等方法的预期语义。
在您的情况下，仅在书籍集合中包含查询参数有什么问题？例如，类似的东西GET /books?state=active。这将返回所有活动书籍的集合（可能始终是 1 本书，但如果将来发生变化怎么办？）您可以从那里向下钻取PUT到规范 URI。
更好的是，建立一个链接关系架构，并在图书收藏的“自我”链接旁边简单地包含一个“活动图书”关系。这样你的客户甚至不需要知道你的 URL 约定；它可以简单地跟随服务器提供的链接。