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

时间:2016-05-28 19:49:02

标签: rest

你的后端有两个型号:

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/

1 个答案:

答案 0 :(得分:2)

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,它表明它应该是一种纯粹的信息检索方法。