URI 中的 REST 父 ID
假设我的模型由一个 Parent 实体组成，该实体通过 children 属性引用一些 Child 实体。根据 REST 原则，特定 Child 的 URI 路径段为 /parent/{parentId}/children/{childId}。
对 Child 执行更新操作时，通常需要 childId 来唯一标识正确的 Child，并认为 parentId 路径中的段是多余的。随着层次结构变得复杂，这种冗余会加剧。
现在我想起来了，它也可能会导致意外的行为：访问具有相同 childId 但具有 不同 parentId 的 URI 可能会导致相同的结果行为，如果程序员不知道的话。当访问不相关的 Parent 下的 Child 时，可能会发生的情况是应该返回客户端错误代码。
目前，我认为也许不应该向 REST API 引入任何层次结构，除非它绝对直观，因为它：
- 使 URI（因此 API）更加复杂。强化可维护性。
- 这种冗余可能会导致用户对访问某些 URI 的结果进行推理。
- 对于不知情的程序员来说，冗余可能会成为一个陷阱。
有没有办法避免这种冗余并仍然符合 REST 原则？
Let's say my model consists of a Parent entity that refers some Child entities, via children property. The path segment of the URI of a specific Child, according to REST principles, would be /parent/{parentId}/children/{childId}.
When performing update operations on a Child, usually childId is all I need in order to uniquely identify the correct Child, deeming the parentId segment in the path redundant. This redundancy aggravates as the hierarchy grows complex.
Now that I think of it, it may also cause unexpected behavior: accessing URIs with the same childId but with different parentId could result in the same behavior, if the programmer isn't aware. What should probably happen when accessing a Child under an unrelated Parent is that a client error code should be returned.
Currently I think that maybe no hierarchy should be introduced to REST API unless it is absolutely intuitive, as it:
- Makes the URI - thus the API - more complex. Hardens maintainability.
- The redundancy may cause users to reason about the outcome of accessing some URIs.
- The redundancy may become a pitfall to the unaware programmer.
Is there a way to evade this redundancy and still conform REST principles?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，只需像这样构建您的 URL...
/children/{childId}由于您可以在服务器端从子级推断出父级，因此没有理由在 URL 中声明它。仅当绝对需要时才应将多个资源放入 URL 中。例如，用户对评论进行投票。由于在数据库端没有正式的方法来确定，您将创建一个类似于..
/voter/{userId}/comment/{commentId}/upvote的网址Yes, just structure your URL like this...
/children/{childId}Since you can infer the parent from the child on the server side, there is no reason to declare it in the URL. You should only put multiple resources in a URL when you absolutely need to. For example, a user voting on a comment. Since there is no formal way to determine on the database side, you would create a url like..
/voter/{userId}/comment/{commentId}/upvote由于 REST 指的是资源，因此它们不一定是分层的。
在类似的 API 中，我有部分、类别和文章。当然，其中每一个都位于另一个之下，但在 REST 中，我将它们指定为section/{id} &文章/{id}。它们仍然是指向各个资源的链接 - 但由于它们可以独立于其父资源，因此在 URI 中指定层次结构并不重要。
如果您确实想在 URI 中指定层次结构，则应检查以确保父级是子级的父级，否则抛出错误 - 以保持层次结构的完整性。
TL;DR
Since REST is referring to Resources, they don't necessarily have to be hierarchical.
In a similar API, I have Sections, Categories, and Articles. Each of these is, of course, under one of the other, but in REST I specify them as section/{id} & article/{id}. They're still links to individual resources - but since they CAN be independent of their parent, the hierarchy isn't important to specify in the URI.
If you definitely want to specify the hierarchy in the URI, you should check to make sure the parent is the parent of the child, and throw an error elsewise - in order to maintain hierarchical integrity.
TL;DR
对我来说，这个问题的答案将由数据建模驱动，对于数据建模，问题是“是否为子模型使用复合键”（如果他使用复合键），因此如果没有使用复合键，则必须将父 ID 放入 URI 中，并且孩子有自己的 id，该 id 不是复合的，因此您可以仅使用带有孩子 id 的 URL。
所以这是数据建模问题！
for me this question answer is going to be driven by data modeling, and for data modeling the question is "using composite key for child model or not" if he is using composite key so you have to put the parent id in URI if not and child have its own id which is not composite so you can just use URL with child id only.
so this is data modeling question!!!