考虑一个ReST API，它提供了一个数据库接口。
服务器是否应该在HTTP 400 Bad Request或PUT请求中使用PATCH进行响应，该请求会尝试为数据库中不存在的列指定新值？服务器应该默默忽略错误吗？服务器应该做一些我在这里没有提到的其他内容吗？
不要默默地忽略请求 除了服务器关闭连接而不发送响应之外，我不知道你怎么可能。
400是好的，因为是409.您可能还想考虑403 Forbidden：服务器理解您的请求但拒绝履行它。
400通常用于形成错误的请求。 403适用于请求格式正确，您的服务器代码能够解析它并了解请求的内容。我认为这里最符合您的要求。
但是，你问题中的一行让我担心：
attempts to specify a new value for a column which does not exist in the database
请求不应该修改数据库中列的值。他们应该修改资源的内容。两者不一样。很容易陷入思考“哦，让我们将这个域对象公开为HTTP资源”的陷阱，但这可能导致可扩展性问题。通常，URI空间中的资源应该比模型对象多。这允许您使用与那些更动态的部分不同的策略来缓存模型的相当静态部分。
例如，在订单处理系统中，递送地址很少发生变化，但进度跟踪器可能每隔几分钟就会发生变化。为两个数据提供不同的URI和不同的缓存策略。
默默地忽略错误是使您的API难以使用的一个方法。除非您提供非常好的文档（有时甚至是那时），在您的API客户端上工作的开发人员不太可能知道他们的请求的某些部分可能会被忽略。因此，他们可能会混淆为什么资源不能反映他们上次PUT的内容。像这样浪费人们的时间不太可能使你的API流行。
如果客户有可能在没有额外价值的情况下重新提交，您应该从spec回复409.
10.4.10 409冲突
由于与资源的当前状态冲突，无法完成请求。此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许。响应主体应该包含足够的信息供用户识别冲突的来源。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题;但是，这可能是不可能的，也不是必需的。
冲突最有可能发生在响应PUT请求时。例如，如果正在使用版本控制并且包含PUT的实体更改为与早期（第三方）请求所产生的资源冲突的资源，则服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应实体可能包含由响应Content-Type定义的格式的两个版本之间的差异列表。
根据我的经验，您不应该默默地忽略其他属性并将PUT / POST视为不存在。考虑消费者使用模型中的可选属性调用API。如果API使用者在可选属性的名称中有拼写错误，则API将以200响应，并且与返回400时相比，消费者将花费更多时间进行调试。通常最令人沮丧的错误来自无辜的错别字，如“laed”而不是“lead”。