REST - 创建业务资源
在公司工资系统的范围内,我们假设有一个PERSON资源,EMPLOYEE是它的一个特例。是可以接受的做:REST - 创建业务资源
POST /api/v1/employees
{
personId = 1, //existing Person
salary = 19,
departmentId = 2
}
这增强了现有的人使其成为一名员工。
在这种情况下,这是可以接受的指使用人的原始ID员工:
GET /api/v1/employees/1
?
我假设你有一个Person类和一个从Person延伸出来的Employee。正如您在JSON中提到的,员工将拥有更多字段,如薪水,部门ID等。
您是否有另一个终端访问人员?像GET /api/v1/persons/1
?
或者所有的访问都是通过GET /api/v1/employees/1
?
它可以使用相同的ID,只要它是第一个扩展名。我想你可能会使用同一个表来存储两者,那就是这个用例出现的原因。
一个使用继承资源的例子,可以在资源中使用带@type的单个端点来标识它们。
PersonResource(考虑到这一点为基类) EmployeeResource(从EmployeeResource扩展)
对于员工资源:
{
"someOtherElement": "value",
"person" : {
"@type" : "EmployeeResource",
"faxNumber" : "35635636",
"email" : "[email protected]",
"phone" : "2503334444",
"contactName" : "name",
"firstName" : "Owner",
"lastName" : "lastName"
...
"address" : {
"@type" : "InternationalAddressResource",
"province" : "AB",
"country" : "Canada",
...
}
}
}
对于IndividualResource:
{
"someOtherElement": "value",
"person" : {
"@type" : "PersonResource",
"email" : "[email protected]",
"firstName" : "Owner",
"lastName" : "lastName"
...
"address" : {
"@type" : "PostalAddressResource",
"province" : "AB",
"country" : "Canada",
...
}
}
}
是的,人员端点仍然存在,在这种情况下,它将作为一个人而不是员工返回与该人相关的数据。 –
通常会有一个@type属性添加到资源中以确定它是哪种类型。用一个例子更新答案。它可能有帮助。 – Lijin
Reffering是好的。但通常我不应该暴露 – Aashish
@Aashish你怎么会提到它而不暴露身份证? –
我在rails上工作,在这里我们通常改变/定制从“GET/api/v1/employees/1”到“/ api/v1/employees”的路线。因此,ID不会暴露 – Aashish