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

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。

是否有意义？