我正在创建一个REST API，例如，我有作者和帖子。
所以我可以获得作者发表的帖子：
/authors/123/posts
或
/posts?authorId=123
我认为构建灵活的API可能是更好的选择。要获得作者的帖子，我会这样做：
/posts?authorId=123&published=true&sort=created&expand=tags,category
所以在这种情况下，我收到来自authorId = 123的所有发布的帖子按创建日期排序，并获取每个帖子的标签和类别。
基本上，我创建了一种映射到每个数据库表的查询语言。
然后，对于常见查询，我创建了特定的端点：
/posts/recent
将独立于作者返回最近的帖子......
我认为/authors/123/posts在使用多个级别时可能会变得复杂。
您怎么看？
更新
经过几次回答，我的想法如下：
当帖子和作者是我将拥有的两个资源时（帖子的例子）：
GET /posts?authorId=123&published=true
POST /posts
PUT /posts
DELETE /posts/123
如果帖子和作者之间存在层次关联，我经常需要作者的帖子，我还会添加以下内容：
GET /authors/123/posts&published=true
如果在资源作者之外不存在帖子，那么之前的2个选项将被替换为：
GET /authors/123/posts?published=true
POST /authors/123/posts
PUT /authors/123/posts
DELETE /authors/123/posts/123
您怎么看？
答案 0 :(得分：2)
神话每个资源必须只有一个路径。你的两个例子都是正确的。
用你的第一个例子：
/authors/123/posts。
当两者之间存在层次关系时有意义，如果您当前的上下文是author，则访问该作者的帖子没有问题。
用你的第二个例子：
/posts?authorId=123&published=true&sort=created&expand=tags,category。
查询在多个方面分发的帖子的整个存储库是有意义的。例如，在您的应用程序中，您可能有一个搜索页面来搜索帖子，这是完美的用例。
就模型视图而言。我们的资源就像模型，我们的网址就像是视图。没有什么能阻止我们为同一个模型使用很多视图。您只需确保使用相同的支持代码来访问存储的数据。有不同的方式（视图）来查看您的数据。
摘要：您可以在项目中使用这两个网址。例如，使用作者页面上的/authors/123/posts列出作者的帖子，并使用帖子搜索页面上的/posts?authorId=123&published=true&sort=created&expand=tags,category。
您还可以查看此帖子中的类似观点：What are best practices for REST nested resources
答案 1 :(得分：0)
我们在项目中使用的经验法则：使用网址路径，例如/authors/123/posts如果两者之间存在明确的层次关系，那么您访问的资源不能生活在另一个的上下文之外。例如，在检索订单行时，可以直接使用/orders/123/lines，因为订单行在订单本身的上下文之外没有任何意义。
在您的情况下，帖子可以清楚地生活在＆＃39;在他们的作者的背景之外。如果您可以按作者，日期，主题等搜索帖子，则将这些值作为查询字符串传递是有意义的。所以在我看来，/posts?authorId=123是前往这里的方式。