Http RESTAPI是否应该静默地忽略更改不存在字段的请求？

考虑提供数据库接口的RESTAPI

---

服务器是否应在试图为数据库中不存在的列指定新值的

PUT

或

PATCH

请求上响应

HTTP 400错误请求

？服务器是否应该静默地忽略该错误？服务器是否应该执行我在这里没有提到的其他操作？

如果客户端可以在没有额外值的情况下重新提交，则应使用409进行响应。从：

10.4.10 409冲突

由于与当前请求冲突，无法完成请求 资源的状态。只有在以下情况下才允许使用此代码： 预计用户可能能够解决冲突并 重新提交请求。响应机构应包括足够的 用于用户识别冲突源的信息。 理想情况下，响应实体将包含足够的信息用于 解决问题的用户或用户代理；然而，情况可能并非如此 可能，但不是必需的

在响应PUT请求时最有可能发生冲突。对于 例如，如果正在使用版本控制并放置实体 包括对资源的更改，这些更改与 在以前的（第三方）请求中，服务器可能会使用409响应 表示它无法完成请求。在这种情况下 响应实体可能会包含一个列表，其中列出了 这两个版本的格式由响应内容类型定义

---

不要默默地忽略请求
除了服务器关闭连接而不发送响应之外，我不知道你怎么能这样做

400是好的，409也是。您可能还想考虑403个禁止：服务器理解您的请求，但拒绝履行它。 400通常用于格式错误的请求。
403适用于当请求的格式足够好，服务器代码能够解析它并理解请求的目的时。我认为这最符合你的要求

然而，你问题中的一句话让我担心：

尝试为数据库中不存在的列指定新值 请求不应修改数据库中列的值。他们应该修改资源的内容。这两者不一样。人们很容易陷入“哦，让我们把这个域对象作为HTTP资源公开吧”的思维陷阱，但这可能会导致可伸缩性问题。通常，URI空间中的资源应该比模型对象多。这允许您使用与那些更动态的部分不同的策略来缓存模型中相当静态的部分

---

例如，在订单处理系统中，交货地址很少更改，但进度跟踪器可能每隔几分钟更改一次。为这两个数据指定不同的URI和不同的缓存策略。

默认忽略错误会使API难以使用。除非您提供非常好的文档（有时甚至如此），否则为您的API开发客户机的开发人员不太可能知道他们的部分请求可能会被忽略。因此，他们很可能会对资源为什么不能反映他们最后投入的内容感到困惑。像这样浪费人们的时间不太可能使您的API流行。

根据我的经验，您不应该默默地忽略其他属性，而将PUT/POST视为不存在。考虑消费者在模型中调用具有可选属性的API。如果API使用者在可选属性的名称中有输入错误，API将以200作为响应，并且使用者将比返回400花费更多的调试时间。通常，最令人沮丧的错误来自于无辜的打字错误，比如“laed”而不是“lead”。

@DonalFellows谢谢。我很感谢你的批判性评论，因为我对这个主题还不太熟悉。我所说的“无声忽略”是指服务器将以

200 OK

响应。