后端数据库中有一个名为 Car 的对象。它包含几个字段：
id
name
age
vinNumber
retailerId
还有一个 API 可以提升添加和编辑汽车的功能：
POST /car - creates a car
PUT /car/{carId} - updates a car
API 的用户可以在 POST 正文中创建汽车时提供姓名、年龄和 vinNumber。
更新汽车时，用户可以编辑姓名和年龄。创建汽车后无法编辑 VinNumber。
另外，retailerId 不可编辑，因为它来自另一个系统到后端数据库。
既然如此，我们有两个字段不应使用 API 进行编辑：vinNumber 和retailerId。
那么，考虑到 REST 幂等性，PUT 请求是否还需要提供 API vinNumber 和 RetailerId 的用户，而这些 API 是之前通过 GET 请求收到的？尽管这些参数不应该是可编辑的？
【问题讨论】：
标签： rest api microservices
需要认识到的重要一点——HTTP 规范描述了 HTTP 请求的语义；这个消息是什么意思？它允许由不同组织实施的客户端和服务器进行协作，而无需两者之间的直接伙伴关系。
关键是通用客户端可以为通用服务器准备请求，而无需带外信息。
PUT，语义上，是服务器更改其当前资源表示以匹配客户端本地副本的请求。
如果“服务器”只是一个贫乏的数据存储（文件系统或文档数据库前面的外观），那么在服务器上执行 PUT 的效果就是将消息体原样写入存储。
REST 和统一接口的重点在于，您的服务器应该始终以与贫血外观理解消息相同的方式理解消息。
同样，您的服务器应该对其响应使用相同的共享语义。
如果您正在使用的表示包括 vinNumber 和 RetailId，那么客户端应该发送这些字段，除非请求将它们从表示中完全删除（这可能会或可能不会被允许，具体取决于它们是否必填）。
服务器应该了解缺少这些字段的请求正在尝试删除它们，而在这些字段中具有新值的请求正在尝试更改它们。然后它可以决定要对该请求做什么，并发送相应的响应。
Roy Fielding 在2002 中写过关于GET 语义的文章：
HTTP 并不试图要求 GET 的结果是安全的。它所做的是要求操作的语义是安全的，因此如果发生任何导致财产损失的事情（金钱，顺便说一句，为了这个定义，被认为是财产）。
同样的想法也适用于 PUT（以及其他 HTTP 方法）；如果实现对请求的处理与语义不匹配，我们会要求实现对财产损失负责。
【讨论】：
根据 PUT 请求文档 - 应提供完整数据（即 vinNumber 和 RetailerId） - https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods
对于这种情况，您可以改用 PATCH。
我们最初所做的也是我多次看到的 POST /car/{carId}
【讨论】：