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