我正在设计和API方案，用于管理评论和讨论线程。 我想有一个enpoint
/discussions/:discussionId
当你GET时，它会返回一个注释数组和一些元数据。
/discussions/:discussionId/comments/:commentId
我还想允许搜索评论以便能够回答以下问题：用户XYZ留下了多少评论？必须指定discussionId是不可行的，所以我想必须有一个
/comments/:commentId
你可以?q=XYZ。然后，人们也可以通过例如
/comments/:commentId?discussion=discussionId
以及上述端点
/discussions/:discussionId/comments/:commentId
变得多余。最终，所有人似乎都倾向于采用扁平的API结构。在野外，我确实看到了很多这样的嵌套端点。
这里的最佳做法是什么？删除嵌套端点？保持两者并处理冗余？也许有更适合的设计？
答案 0 :(得分：2)
我喜欢做的是使用CQS原则公开信息。如果将查询与命令分开，则可以公开以用例使用方式返回数据的专用契约。
基本上这意味着在你的情况下你可以：
/discussions
...映射到查询处理程序FindDiscussions（），它提供了前x个讨论和主要属性（标题，作者，评论数量等）的列表。
获取讨论的详细信息：
/discussions/{discussionId}
...映射到查询处理程序FindDiscussionDetails（），它提供了讨论的所有细节以及前x条评论。
获得其他评论：
/comments/{discussionId}?{other parameters}
...映射到查询处理程序FindComments（），它为您提供所有注释（按日期等过滤）。
要获取用户的评论总数，这是您可以与用户存储的信息（非规范化）并获得如下信息：
/users/{userId}
...映射到查询处理程序FindUserDetails（），它为您提供用户详细信息以及注释总数。无需动态计算，只需在快速查询中获取非规范化值。
这同样适用于命令。
优点是您可以为您的用例公开客户端所需的内容，仅此而已。
阅读here。