Restful 设计 : when to use sub-resources?

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 4 年前。

Improve this question

设计资源层次结构时，什么时候应该使用子资源？

我曾经认为，当一个资源不能离开另一个资源而存在时，它应该被表示为它的子资源。我最近遇到了这个反例:

• 员工在所有公司中都是唯一可识别的。
• 员工的访问控制和生命周期取决于公司。

我将其建模为:/companies/{companyName}/employee/{employeeId}

请注意，我不需要查找公司来找到员工，我应该这样做吗？如果我这样做，我就会付出代价来查找我不需要的信息。如果不这样做，此 URL 会错误地返回 HTTP 200:

/companies/{nonExistingName}/employee/{existingId}

1. 我应该如何表示一个资源属于另一个资源的事实？
2. 如果没有其他资源，无法识别资源这一事实，我该如何表示？
3. 子资源意味着什么关系而不是为了建模？

Answer 1

一年后，我以以下妥协结束(对于包含唯一标识符的数据库行):

1. 在根处为所有资源分配一个规范 URI(例如 /companies/{id} 和 /employees/{id})。
2. 如果一个资源不能离开另一个资源而存在，则应将其表示为其子资源；但是，请将该操作视为搜索引擎查询。这意味着，不是立即执行操作，而是简单地返回指向规范 URI 的 HTTP 307(“临时重定向”)。这将导致客户端重复针对规范 URI 的操作。
3. 您的规范文档应该只公开与您的概念模型匹配的根资源(不依赖于实现细节)。实现细节可能会发生变化(您的行可能不再是唯一可识别的)，但您的概念模型将保持不变。在上面的示例中，您将告诉客户有关 /companies 的信息，但不告诉客户有关 /employees 的信息。

这种方法具有以下优点:

1. 它消除了不必要的数据库查找的需要。
2. 它将健全性检查的数量减少到每个请求一次。最多，我必须检查员工是否属于公司，但我不再需要对 /companies/{companyId}/employees/{employeeId}/computers/{computerId} 进行两次验证检查>.
3. 它对数据库可扩展性有着复杂的影响。一方面，您可以通过在更短的时间内锁定更少的表来减少锁争用。但另一方面，您也增加了死锁的可能性，因为每个根资源必须使用不同的锁定顺序。我不知道这是净 yield 还是净损失，但令我感到安慰的是 database deadlocks cannot be prevented无论如何，由此产生的锁定规则更容易理解和实现。如有疑问，请选择简单性。
4. 我们的概念模型保持不变。通过确保规范文档仅公开我们的概念模型，我们可以在将来随意删除包含实现细节的 URI，而不会破坏现有客户端。请记住，只要您的规范将中间 URI 的结构声明为未定义，就没有什么可以阻止您公开中间 URI 中的实现细节。