2

假设我有以下对象图，客户端可以在 HTTP PUT 请求中提交以更新我的父对象

{
  "Id": 123,
  "FirstName": "Joe",
  "LastName": "Smith",
  "Schools": [
    {
      "Id": 444,
      "Name": "Fun University"
    },
    {
      "Id": 555,
      "Name": "Unfun University"
    }
  ]
}

在我的服务中，更新学校的唯一方法是通过学生。但是，我不一定能阻止客户端修改“444”id。

我的问题是： 1. 仅在服务器上验证 id 为 444 的学校属于 id 为 123 的学生是否足够安全？2. 或者，我的客户是否需要使用学生服务向学生提出请求，然后使用学生服务上的学校列表，调用学校服务（我将创建）并在那里进行 PUT？

在场景 1 中，我将使用http://www.mydomain.com/api/students/123 (PUT) 更新整个对象。

在场景 2 中，我将使用http://www.mydomain.com/api/schools/444 (PUT)仅更新学校对象

到目前为止，我的意图是方法#1，但这不是一个好方法吗？

4

1 回答 1

2

够安全吗...

仅在服务器上验证 id 为 444 的学校属于 id 为 123 的学生

为什么要检查依赖项？
如果您只是编辑一所学校，那么这对学生资源应该没有任何兴趣。

只需发出您的PUT /student/123/school/444并处理它。如果您的客户有更直接的访问权限是有意义的，那么只需/school/{ID}将其作为一项新服务实施即可。

我认为你真正需要的是一个ID-not-changeable constraint. 只需禁止任何用户通过 put 请求更改资源的 ID。很少需要更改 ID，并且由于其影响应格外小心处理（届时必须更新所有学生的关系）。

APUT /students/123不应该被允许改变学校本身，而只能改变学生与他们的关系（从学生中删除它们或添加新的附加项）。
您处理此问题的代码完全取决于您。

于 2013-03-28T15:09:42.993 回答