【问题标题】:REST Update Child Object - Prevent Id field From ChangingREST 更新子对象 - 防止 Id 字段更改
【发布时间】:2013-03-19 01:55:53
【问题描述】:

假设我有以下对象图,客户端可以在 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,但这不是一个好方法吗?

【问题讨论】:

    标签: rest put


    【解决方案1】:

    够安全吗……

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

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

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

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

    不应允许PUT /students/123 更改学校本身,而只能更改学生与他们的关系(从学生中删除它们或添加新的附加项)。
    处理这一切的代码完全取决于您。

    【讨论】:

    • 感谢您的回答。 id-not-changeable 是否有某种标准?无论哪种情况,我认为选择 2 更好。
    • 我也这么认为。在处理这些放置请求时,我通过 URL 中提供的 ID 获取资源,并从请求中删除 Request-Body 中发送的 ID。这只是忽略了正文中发送的 ID 值。您可以与 URL-ID 进行匹配并将错误返回给用户和/或记录它。 REST 表示 PUT 应该在 URI 引用的实体上工作。在您的文档中添加一条客户无法更改 ID 的行,这样就可以了。
    猜你喜欢
    • 2018-06-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-06-15
    相关资源
    最近更新 更多