一对多和多对多关系的REST URL设计

您的后端有两种型号：

One Company to Many Employees.

您希望完成以下任务：

Get all Companies
Get a Company by ID
Get all Employees for a Company
Get all Employees 
Get a Employee by ID

当您的模型具有1:M关系时，处理REST URL的最佳实践是什么？这就是我到目前为止的想法：

/companies/
/companies/<company_id>/
/companies/<company_id>/employees/
/employees/
/employees/id/<employee_id>/

使用

POST

：

/companies/add-employee/
/employees/add-company/

---

URI在我看来很好，除了最后一个，它在路径中不需要额外的“id”。此外，我更喜欢单数形式的单词，但这可能就是我自己：

/company/
/company/<company_id>/
/company/<company_id>/employee/
/employee/
/employee/<employee_id>/

有雇员的代表。我更喜欢

PUT

，因为它是。这意味着，如果操作似乎失败（超时、发生网络错误等），则可以重复操作，而无需检查前一个操作是否在服务器上“真的”失败。

PUT

需要在服务器端进行一些额外的工作，以及一些要正确链接到的额外工作（例如表单），但提供了一种更健壮的设计

作为替代方案，您可以使用

POST /employee

以员工代表为主体。这并不能提供任何保证，但更容易实现

不要使用

GET

添加员工（或任何相关内容）。这将与该标准背道而驰，该标准规定它应该是一种纯粹的信息检索方法

PUT /employee/123

POST /employee