Question

你的后端有两个型号：

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>/

现在让我们假装One Company有很多型号。用于“将员工添加到公司”的最佳名称是什么？我可以想到几种选择：

使用GET：

/companies/<company_id>/add-employee/<employee_id>/
/employees/<employee_id/add-company/<company_id>/

使用POST：

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

Answer 1

URI对我来说很好，除了最后一个，不需要额外的＆＃34; id＆＃34;在路上。此外，我更喜欢单数形式的单词，但这也许只是我：

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

URI实际上并不重要，并且可以在以后正确完成时随时更改。也就是说，所有URI都链接到，而不是硬编码到客户端。

就添加员工而言，我可能会使用上面定义的相同URI和PUT方法：

PUT /employee/123

代表员工。我更喜欢PUT，因为它是idempotent。这意味着，如果操作似乎失败（超时，网络错误发生，无论如何），操作可以重复，而无需检查前一个操作是否真的＆＃34;在服务器上失败了。 PUT需要在服务器端进行一些额外的工作，还有一些额外的工作要正确链接到（例如表单），但提供了更强大的设计。

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

POST /employee

将员工代表作为正文。这不提供任何保证，但更容易实现。

不要使用GET添加员工（或其他任何事情）。这将违背HTTP Specification for the GET method，它表明它应该是一种纯粹的信息检索方法。

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

1 个答案: