Question

假设我有一个无意义的REST API，它返回以下资源：

GET /person/123 HTTP/1.1

{
    "id": 123,
    "name": "Big Mike",
    "name_caps": "BIG MIKE",
    "created": "2016-01-07T13:24:33+00:00"
}

服务器实际上并不存储name_caps，而是每次都从name派生。

我对HTTP PUT的理解是你必须发送带有请求的完整资源，甚至是那些没有改变的东西。因此：

PUT /person/123 HTTP/1.1

{
    "id": 123,
    "name": "Little Ron",
    "name_caps": "LITTLE RON",
    "created": "2016-01-07T13:24:33+00:00"
}

但这有点让我感到困惑，原因有二：首先，它为客户提供了尝试修改id和created这些应该是不可变的值的潜力。其次，它要求客户端派生name_caps以维护资源的完整性，即使服务器不打算存储该值。

如果没有切换到PATCH，服务器应该对这些属性进行多少验证？改变后的id / created - 或name_caps不等于upper(name)是否会被彻底拒绝？或者服务器应该接受（或要求？）它们，但是无论它们是什么，都要默默地丢弃这些值？

Answer 1

据我了解，您正在开发服务器端。实际上，PUT传统上用于更新数据层中的现有记录。因此，了解记录的id非常有用（不会出现使用其他属性查询数据库的问题，比如名称，并获得两个类似的记录）。同样，传统上您应该将所有参数发送到服务器以将其保存到数据库，或者在数据层中使用的任何参数。另一方面，name_caps不是数据层中的属性，而是它的计算值。因此客户端不需要发送此参数。

在一天结束时，如果您和您的团队控制着服务器和客户端的开发，并且您不打算向全世界开放API以供其他开发人员使用，事实上，您可以以您认为更有意义的方式开发服务器。在这种情况下，您可以只期望所有参数，但id为PUT调用的可选项。当然在考虑限制的宁静术语时，PATCH是用于将部分数据发送到服务器以进行更新操作的正确方法，但是许多API都没有使用它，主要是使用GET，POST，PUT方法和前端开发人员习惯了他们。入门级前端开发人员可能会惊讶地发现您需要他们调用PATCH。

有意义吗？

如何在HTTP PUT中处理不可变和派生字段？

1 个答案: