考虑一个ReST API，它提供了一个数据库接口。
对于尝试为数据库中不存在的列指定新值的PUT或PATCH请求，服务器是否应使用HTTP 400 Bad Request进行响应？服务器应该静默地忽略该错误吗？服务器应该做一些我在这里没有提到的其他事情吗？
不要默默地忽略请求
除了服务器关闭连接而不发送响应之外，我不知道你怎么能这样做。
400和409一样好。你可能还想考虑403禁止：服务器理解你的请求，但拒绝履行。
400通常用于格式错误的请求
403适用于当请求的格式足够好，以至于您的服务器代码能够解析它并理解请求的用途时。我认为这非常符合你的要求。
然而，你的问题中有一句话让我担心：
尝试为数据库中不存在的列指定新值
请求不应修改数据库中列的值。他们应该修改资源的内容。两者不一样。人们很容易陷入这样的陷阱："哦，让我们把这个域对象公开为HTTP资源"，但这可能会导致可伸缩性问题。通常，URI空间中的资源应该比模型对象多。这允许您使用不同于动态部分的策略来缓存模型中相当静态的部分。
例如，在订单处理系统中，交付地址很少更改，但进度跟踪器可能每隔几分钟就会更改一次。为这两个数据提供不同的URI和不同的缓存策略。
无声忽略错误是使API难以使用的一个方法。除非您提供非常好的文档(有时甚至是这样)，否则为API开发客户端的开发人员不太可能知道他们的部分请求可能会被忽略。因此，他们可能会感到困惑，为什么资源没有反映他们上次PUT的内容。像这样浪费人们的时间不太可能让你的API流行起来。
如果客户端可以在没有额外值的情况下重新提交，则应使用409进行响应。来自规格：
10.4.10 409冲突
由于与当前资源的状态。只有在以下情况下才允许使用此代码预计用户可能能够解决冲突，并且重新提交请求。响应主体应包括足够的用于用户识别冲突源的信息。理想情况下，响应实体将为用户或用户代理来解决问题；然而，这可能不是可能的，而不是必需的。
冲突最有可能发生在对PUT请求的响应中。对于例如，如果正在使用版本控制并且实体为PUT包括对资源的更改，这些更改与早期(第三方)请求，服务器可能会使用409响应以指示它无法完成请求。在这种情况下响应实体可能包含以下差异的列表两个版本的格式由响应内容类型定义。
根据我的经验，您不应该默默地忽略其他属性，并将PUT/POST视为不存在。考虑一个消费者调用模型中具有可选属性的API。如果API使用者在可选属性的名称中有错别字，API将以200响应，使用者将比返回400花费更多的调试时间。通常，最令人沮丧的错误出现在诸如"laed"而不是"lead"之类的无辜拼写错误中。