我正在构建REST API，并且我有一些关系使我的链接很长。它们对我有意义，但它是一团糟。我不确定处理这个问题的最佳方法是什么。拥有如此长的链接是一个问题吗？我是否违反了这些原则？我应该如何处理这样的关系？
以下示例有点人为，但它说明了我尝试做的事情。
公司有许多部门。每个部门都有许多员工。每个员工都可以拥有多台计算机。每个计算机都可以包含许多文档。
特定文件的GET路径为：
/companies/:companyId/departments/:departmentId/employees/:employeeId/computers/:computerId/documents/:documentId
每个ID在该层中是全局唯一的 - 整个系统中没有两个文档ID相同，但文档ID可能与员工ID相同。
这对我来说很有意义，因为每一层只与它上面的一个东西相关联。部门只属于一家公司，员工只属于一个部门，一台计算机只属于一个员工，一份文档只属于一台计算机。
我可以将它们分解为单独的端点，例如/computers，但是我怎么知道在哪里打破它们？为什么我会选择/computers作为端点，而不是/employees/:employeeId/computers？
答案 0 :(得分：3)
在这个例子中，我将每个资源都移到顶层。每个顶级资源都可以将下一个“级别”作为成员。所以，
/companies
/companies/{id}
/companies/{id}/departments
/departments
etc..
如果最终用户实际需要操作集合的内容，我只会添加子资源。
深度嵌套的资源存在问题。当您获得业务要求以查找为公司{id}工作的所有员工（无论是哪个部门）时，3个月内会发生什么？将员工作为顶级资源，您可以添加对GET /employees?companyId={id}的支持。在您上面提到的设计中，您的选择都很糟糕。在您正式化嵌套结构时，您放弃的资源之间的关系具有很大的灵活性。
就您的一些具体问题而言：
我正在构建REST API
REST在URI设计方面完全不可知。
我有一些关系让我的链接很长。它们对我有意义，但它是一团糟。 [..]链接如此长，这是一个问题吗？
最终用户将永远不会输入这些内容。如果您的API确实是RESTful，那么客户端将使用您返回的链接，并且他们不必在其中键入它们。在RESTful系统中，我希望“我有一些X”的关系可以保存在一个链接中，而不仅仅是通过URI的形状来记录。我同意他们是长期的，我会因上述原因改变它们，但我不认为你的具体问题是改变它们的理由。
我是否违反了这些原则？
不是我知道的。