在RESTful API中处理嵌套资源的正确方法是什么？

Question

考虑到我正在使用以下RESTful APIendpoint：

• /users/：显示所有用户
• /users/$user_id/：显示特定用户
• /users/$user_id/posts/：按用户显示所有帖子
• /users/$user_id/posts/$post_id/：按用户显示特定帖子

这个数据模型中的约束：一篇文章总是有一个用户。

“处理嵌套资源”是指处理CRUD操作。

我应该在 /users/$user_id/posts/ 终结点上实现 CRUD 操作（POST、PUT、PATCH、DELETE），还是应该创建另一个终结点 /posts/ 并在那里处理 CRUD 操作，同时保持第一个终结点为只读？

抱歉，如果这个问题已经以SO的另一种形式存在。：-）RESTful API周围有太多的“FUD”。

提前感谢任何提示/澄清！

亲切的问候，K。

Answer 1

在Roy Fielding对REST的澄清之后，我建议您不要担心URL的设计：

REST API 不得定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由地控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的 URI，例如在 HTML 表单和 URI 模板中完成的 URI。[此处的失败意味着客户端由于带外信息而采用资源结构，例如特定于域的标准，该标准是面向数据的，相当于RPC的功能耦合]。

测试API的RESTfull的一个好方法是用统一ID替换所有精心构建的URI，并查看客户端是否可以使用这些信息。如果不是的话，你依赖带外信息，可以改善你的Rest。但是，类似于第n级数据库规范化，您可能希望少一点“正确性”，以便使所有参与者的工作更容易。需要多少正确性取决于您的域的不稳定性，以及您是否希望API用户数量更少或更多。

如果您想在URI中编码带外信息，我会尽量限制所需的信息。由于/user/$user_id/post/$post_id/需要用户知道三件事（URL设计、User ID、Post ID），似乎有一些替代方案可以让用户更加无知；-）

• /posts/$post_id：更好，因为您的用户只需要一个 id 和资源类型来构造 URI
• /$resource_id：最好，但需要全局唯一 ID

Answer 2

您应该在现有的 /posts/ 和 /posts/$post_id/ 终结点上实现这些操作。很少有充分的理由创建表示相同资源的多个终结点。为什么要让他们知道他们只能在/users/$user_id/posts/$post_id/上GET，但必须转到/posts/$post_id/才能删除？

有时，人们将其实现为

/users/: show all users
/users/$user_id/: show specific user
/users/$user_id/posts/: show all posts by user  -- GET only

/posts/: show all posts                         -- All operations
/posts/$post_id/: show specific post by user    -- All operations

他们使用/user/$user_id/post/作为对用户帖子的非规范引用。虽然我不能称之为错误，但最好坚持每个资源使用一个endpoint。过滤器参数没那么难。