我有一个Post实体列表，每个帖子都有一个Comment实体列表。Post实体是一个组合对象。没有帖子，系统中就不存在评论。
URI 示例：
/posts/3453/comments/8547
这将检索特定评论，也用于删除和更新特定评论。现在，如果我的 API 有这样的东西会不会更好：
/posts/3453/comments/1
第一个 URI 中的评论 id 8547 与最后一个相同，但 id 在帖子的上下文中。它从一开始，随着更多评论的添加而增加。但是，如果您有 10 条 id 为 1-10 的评论，然后删除数字 5，它是否应该以某种方式更新 id 以便应用 1-9？
这听起来合理吗？我刚刚开始考虑，还是应该只使用数据库中的唯一 ID（主键）？如果没有，您将如何创建这种 id？
数字8547和1只是看起来一样，但它们代表不同的概念：8547是标识符，1而是序列号。序列号可以更改，但 ID 不能更改。
我建议使用带有 ID 的 URI 来标识特定的评论资源，并添加一个具有查询功能的 UIR，以便按其序列号搜索评论资源，如下所示：
/posts/3453/comments?sequence=1
这样就不会有关于“规范”资源 URI 的问题，但客户端将能够查询评论而无需提供完整的标识。
如果您选择通过序列号来识别评论，那是您的偏好。如果在您的应用程序的概念中，将评论的唯一标识设置为与帖子标识符相关的序列号是有意义的，只要记录在案，这就是完美的设计。
您的重新排序方法至少有两个主要缺点，这可能会导致您的应用程序 URI 设计存在缺陷。第一个缺点是 URI 上的 GET 方法应该是可缓存的，重新排序打破了这个合同，因为第 2 项没有改变，但是因为第 1 项你现在改变了 /2 的含义。接下来，这显然会破坏人们可能已经创建的链接。
我确实喜欢序列查询参数的概念，但是我认为从我对您的问题的有限理解来看，仅仅使用标识符是有意义的，因为我上面列出的两个缺点不再是问题。
我肯定会使用评论的实际 ID，而不是使用索引方案。原因是如果连续有多个更新会发生什么？用户 A 删除了索引 2 的评论，同时用户 B 删除了索引 3 的评论。那么，哪些评论真的应该被删除呢？实际删除将由执行顺序决定。如果您使用真实 ID，则不会有任何争用。