URI中的REST父ID

假设我的模型由一个Parent实体组成，该实体通过children属性引用一些Child实体。根据REST原则，特定Child的URI的路径段将为/parent/{parentId}/children/{childId}。URI中的REST父ID

当在Child执行更新操作，通常childId是我需要的，以便唯一识别正确Child，认为在路径冗余的parentId段。随着层次结构变得复杂，这种冗余会加剧。

现在我想起来了，这也可能会导致意外的行为：访问的URI具有相同childId但不同parentId可能会导致相同的行为，如果程序员不知道。在不相关的Parent下访问Child时可能会发生什么情况，应该返回客户端错误代码。

目前，我想，也许没有等级应出台REST API，除非它是绝对直观的，因为它：

有没有办法避开这种冗余，仍然符合REST原则？

来源

2012-02-19 yair

REST是一套原则，而不是一个标准。 – gioele 2012-02-19 18:33:50

什么是URI的“结果”？（有人使用任何类型的API希望能够预测操作的结果，至少在基本水平上。） – 2012-02-19 18:44:07

@DonalFellows - 访问URI的结果。我编辑了你的问题:)。问题是这种API不够可预测。 – yair 2012-02-19 18:49:36

是，仅仅构造你的URL是这样的...

/children/{childId}

既然你可以推断在服务器端的孩子家长，没有理由宣布它的URL。您绝对需要时只应将多个资源放在网址中。例如，用户对评论进行投票。由于没有正式的方式，以确定在数据库端，你将创建一个URL如..

/voter/{userId}/comment/{commentId}/upvote

2012-02-19 18:19:03 Dave

所以你说的是我的观察是正确的，对吧？有没有可以添加的参考链接？谢谢。 – yair 2012-02-19 20:09:41

是的，你观察到你显示的url结构是多余的是正确的。但说实话，我不知道从头顶上的一个很好的参考。如果其他人发现了更详细的说明或引用说明/等的好文章/参考资料，然后上传/接受他们的答案。 – Dave 2012-02-19 20:28:55

由于REST指的是资源，他们并不一定是分层的。

在类似的API中，我有章节，类别和文章。当然，这些中的每一个都属于另一个，但在REST中，我将它们指定为/ {id} &文章/ {id}。他们仍然是个人资源的链接 - 但由于他们可以独立于他们的父母，所以层次结构在URI中指定并不重要。

如果您确定要在URI中指定层次结构，则应该检查以确保父项是子项的父项，并且另外引发错误 - 以保持层次完整性。

TL; DR

2012-02-19 18:21:00 Navarr

看起来戴夫和你说的有点相同，所以我会问你同样的问题：我的观察是否正确，然后呢？有没有可以添加的参考链接？谢谢。 – yair 2012-02-19 20:10:34

这有点多余，我认为你不能找到真正的参考链接。毕竟REST是一种方法论。考虑这样：OOP。你有对象。有时候，他们只与他们的父母有关，而有时候他们是独立的。后者是你在我给出的结构中所反映的。 – Navarr 2012-02-20 05:07:56

对我这个问题的答案是要通过数据建模来驱动，并对问题的数据建模是“对子模型使用组合键”，如果他使用组合键，那么如果不是，则必须将父ID放在URI中，并且child具有其自己的非复合ID，因此您可以将URL与仅限儿童身份证。

所以这是数据建模的问题！

2013-09-04 15:08:00

回答