根据此处的示例提出这个问题What are best practices for REST nested resources?
如果您想获取员工工作的公司，端点会是什么样子？我可以看到的选项是：
GET /companies?employeeId=x 可能会返回employeeId=x 的公司列表GET /companies/by-employee/{employeeId} 将返回一家公司。这个端点从 Linux 系统上的 /dev/disks/ 符号链接中获得了一些灵感。它基本上通过所有子实体给公司起别名GET /employees/{employeeId}/company 将返回单个公司并颠倒员工与公司之间的关系【问题讨论】：
标签： rest api-design restful-url
如果您想获取员工工作的公司，端点会是什么样子？
REST 不在乎您对资源标识符使用什么拼写。
想想浏览器在加载 HTML 页面时的工作方式。假设有一个img标签；标签为浏览器提供了它需要的语义上下文，以便它可以发送对图像的请求（特别是发送带有其首选 image 类型的请求）。浏览器不必解析 URL、查找文件扩展名或类似的东西来确定资源是图像。
试图将您的语义编码到 URI 中是错误的方法；语义属于links。
如果你正在设计一个 REST API，你想要的是类似于
Link: </F4EEFDD3-44D9-41AD-8299-620ECD8765DB>; rel="https://schema.org/Organization"
翻译：这个链接“指向”一个资源，它是当前上下文的组织。
客户端和服务器需要有一个契约来描述哪些链接是可能的，以及它们的含义，就像 HTML 规范描述 a elements、img elements 等的语义一样。
如果你有这部分，那么客户端通过跟踪链接来遵循协议，服务器可以选择他们喜欢的任何链接拼写（例如，充分利用caching）。
正如您所看到的，从客户端的角度来看，标识符的拼写并不重要（这与变量名的拼写并不重要这一事实非常相似）。
Link: </F4EEFDD3-44D9-41AD-8299-620ECD8765DB>; rel="https://schema.org/Organization"
Link: </companies?employeeId={employeeId}>; rel="https://schema.org/Organization"
Link: </companies/by-employee/{employeeId}>; rel="https://schema.org/Organization"
Link: </employees/{employeeId}/company>; rel="https://schema.org/Organization"
/companies?employeeId={employeeId} 是一个方便的标识符，因为您还可以通过 HTML 的 form processing rules 来利用它。
/companies/by-employee/{employeeId} 和 /employees/{employeeId}/company 可能很方便，因为您可以利用 relative resolution 和点段链接到标识符层次结构中方便位置的其他资源。
推荐观看：蒂尔科夫的REST: I Don't Think It Means What You Think It Means。
【讨论】：