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