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

假设我有一个返回以下资源的无意义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\u 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\u caps

，以保持资源的完整性，即使服务器不会费心存储该值

---

除了切换到

补丁

，服务器应该对这些类型的属性执行多少验证？是否应彻底拒绝更改的

id

/

创建的
--或不等于
上限（名称）
的
名称？或者服务器是否应该接受（或要求？）这些值，但不管它们是什么，都会自动放弃这些值？
据我所知，您正在开发服务器端。实际上，传统上，PUT用于更新数据层中的现有记录。因此，了解记录的id非常有用（不必使用另一个属性（如name）查询数据库并获得两个类似的记录）。同样，传统上，您应该将所有参数发送到服务器，以将其保存到数据库中，或者保存在数据层中使用的任何内容中。另一方面，name_caps不是数据层中的属性，而是计算值。因此，客户端不需要发送此参数

最后，如果您和您的团队控制着服务器端和客户端的开发，并且您不打算向世界开放API供其他开发人员使用，那么实际上，您可以以您认为更有意义的方式开发服务器。在这种情况下，除了id之外的所有参数都可以作为PUT调用的可选参数。当然，从restful的角度来看，补丁是将部分数据发送到服务器进行更新操作的正确方法，但是很多API都没有使用它，大多数使用GET、POST、PUT方法，前端开发人员已经习惯了它们。入门级前端开发人员可能会惊讶地看到您要求他们调用补丁

这有意义吗