【问题标题】:API Status Page Response CodesAPI 状态页面响应代码
【发布时间】:2017-06-06 17:39:49
【问题描述】:

(这是一个抽象的哲学问题。但我相信它有客观的具体答案。)

我正在编写一个 API,我的 API 有一个“状态”页面(例如,https://status.github.com/)。

如果我确定状态的任何逻辑都表明一切正常,我的计划是返回 200 OK,并返回一个 JSON 响应,其中包含关于我的状态页面测试的每项服务的更多信息。

但如果我的逻辑表明 API 已关闭怎么办?说数据库没有响应什么的。

我想我想返回 500 INTERNAL SERVER ERROR(或 503 SERVICE NOT AVAILABLE)以及包含更多详细信息的 JSON 响应。

但是,这是否违反了 HTTP 状态代码规范?这会让最终用户感到困惑吗?在这种情况下,我的 状态页面本身 工作得很好。所以也许它应该返回200?但这意味着任何使用它的人都必须深入研究主体,寻找特定参数来确定 API 的状态,而不是仅仅检查 HTTP 状态代码。 (另外,如果我的状态页面本身损坏了,我可以接受最终用户认为 API 已关闭,因为这是一个非常糟糕的信号......)

想法?是否有关于状态页面应该如何工作的官方协议?

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

【问题讨论】:

    标签: http http-headers http-status-codes


    【解决方案1】:

    对我来说,页面应该返回200,除非它本身有问题。确实,检查响应的状态代码比解析更容易,但使用 HTTP 状态代码对应用程序信息进行编码会破坏人们(和蜘蛛)的期望。如果蜘蛛通过您的页面并看到 500 或 503 会认为您的网站有问题的页面,而不是该页面正常并且表明该网站已关闭。

    此外,正如您所注意到的,无法区分 服务已关闭状态页面已关闭 两种情况,最后一种情况是唯一的应该发送500。另外,如果您显示多个服务,例如 twitter status page 怎么办?使用200

    相关:https://stackoverflow.com/a/943021/1536382https://stackoverflow.com/a/34324179/1536382

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2016-04-28
      • 1970-01-01
      • 1970-01-01
      • 2020-01-14
      • 1970-01-01
      • 2011-03-16
      • 2012-11-25
      • 1970-01-01
      相关资源
      最近更新 更多