【问题标题】:Is it appropriate to use HTTP status codes for non-HTTP errors?对非 HTTP 错误使用 HTTP 状态代码是否合适?
【发布时间】:2015-03-14 19:27:30
【问题描述】:

我认识一个正在编写 API 并希望使用 HTTP 状态代码来报告查询结果的人。例如如果用户调用example.com/api/product_info?product_id=X,并且该产品不存在,它将返回HTTP状态400: Bad Request。我认为,由于这是一个有效的调用(即实际的 HTTP 请求没有格式错误),它应该返回一个 200 代码响应,并且响应的正文类似于 {status: 'error'; message: 'No such product'}

所以我的问题是,

1) 如上例所示,使用 HTTP 状态码来传达非 HTTP 程序状态是否合适?

2) 是否有一些标准或至少广泛使用的规范来描述何时适合使用 HTTP 状态代码?

【问题讨论】:

  • 当客户询问不存在的产品资源时,我认为 404 更适合您的情况。当事情没有按预期进行时,您应该返回 4XX 或 5XX。 This 可能会有所帮助。 2.HTTP specification
  • @FrAn 不确定这是否真的是资源不存在的情况。再举个例子,如果 api 调用是/setprice?product=X&price=Y,如果产品 X 存在,但 Y 不是可接受的价格(例如,当最低价格为 5 美元时为 1 美元),您会返回什么响应?还是 404?
  • 在这种情况下,我会返回 400 或 403,在这种情况下,客户正在尝试设置价格,但价格值是不可接受的,而不是尝试获取产品,所以没有 404。这是值得商榷的问题。

标签: http-status-codes api-design


【解决方案1】:

前几天我实际上只是在谈论这个 - http://blogs.mulesoft.org/api-best-practices-response-handling/

您的状态码应该反映 API 的响应,因为 200 表示“OK”并且应该用于成功返回的数据。但是,201 应该用于创建的项目。

如前所述,如果用户尝试调用但失败(即:users/?id=5),服务器可能会返回 400 以通知用户这是错误请求或 404如果资源不存在。

这也取决于操作 - 如果他们正在搜索用户并且没有响应,我不会返回错误,只是 200 没有找到结果。但是,如果他们试图对不存在的用户执行 PUT 或 PATCH,我会告诉他们一个错误 - 因为他们的应用程序中的某个地方可能存在问题。

在上面发布的链接中,您会发现更多状态代码,但使用状态代码的最大优势之一是它通过标头通知客户端服务器实际发生的情况。这使他们能够进行相对快速(且内存不足)的检查,而不必反序列化正文并循环遍历数组以查找错误键。

本质上,您是在为他们提供工具,让他们快速轻松地了解正在发生的事情——我认为每个(理智的)开发人员都会欣赏这一点。

希望这会有所帮助! - 迈克

【讨论】:

    猜你喜欢
    • 2021-10-21
    • 2011-06-14
    • 1970-01-01
    • 2013-11-20
    • 2021-04-07
    • 2023-02-12
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多