ReST API是否应该静默忽略更改不存在的字段的请求？

Question

考虑一个提供数据库接口的ReST API。

服务器是否应该在HTTP 400 Bad Request或PUT请求上使用PATCH进行响应，该请求会尝试为数据库中不存在的列指定新值？服务器应该默默忽略错误吗？服务器应该做一些我在这里没有提到的其他内容吗？

Answer 1

请勿默默忽略该请求
除了服务器在没有发送响应的情况下关闭连接之外，我不知道你怎么可能。

400是好的，和409一样。您可能还想考虑403 Forbidden：服务器理解您的请求但拒绝履行它。

400通常用于形成错误的请求 403适用于请求格式正确，您的服务器代码能够解析它并了解请求的内容。我认为这最符合您的要求。

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

尝试为数据库中不存在的列指定新值

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

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

Answer 2

无声地忽略错误是使您的API难以使用的一个方法。除非您提供非常好的文档（有时甚至是那时），在您的API客户端上工作的开发人员不太可能知道他们的请求的某些部分可能会被忽略。因此，他们可能会混淆为什么资源不能反映他们上次PUT的内容。像这样浪费人们的时间不太可能使你的API流行。

Answer 3

如果客户可以在没有额外价值的情况下重新提交，您应该从spec回复409.

  

10.4.10 409冲突

     

由于与当前的冲突，请求无法完成   资源的状态。此代码仅在以下情况下允许   预计用户可能能够解决冲突   重新提交请求。响应机构应该包括足够的内容   用户识别冲突根源的信息。   理想情况下，响应实体将包含足够的信息   用户或用户代理来解决问题;但是，这可能不是   可能而且不是必需的。

     

最有可能发生冲突以响应PUT请求。对于   如果正在使用版本控制并且实体是PUT   包括对资源的更改与资产的更改   在早期（第三方）请求中，服务器可能会使用409响应   表示无法完成请求。在这种情况下，   响应实体可能包含两者之间的差异列表   这两个版本采用响应Content-Type定义的格式。

Answer 4

根据我的经验，你不应该默默地忽略其他属性并将PUT / POST视为不存在。考虑消费者使用模型中的可选属性调用API。如果API使用者在可选属性的名称中有拼写错误，则API将以200响应，并且与返回400时相比，消费者将花费更多时间进行调试。通常最令人沮丧的错误来自无辜的错别字，例如＆＃34; laed＆＃34;而不是＆＃34;领导＆＃34;。