【问题标题】:Defining Status Codes定义状态码
【发布时间】:2014-06-05 13:43:48
【问题描述】:

我正在为 Web 应用程序内部的第 3 方 api(电子邮件套件)构建一个包装器,可在内部和通过自己的 api 访问。例如,这些方法将电子邮件地址和订阅列表作为参数并返回结果代码。

所以基本上我想:

定义状态码以显示不同的成功/失败状态。

例如成功:

  • 已创建新联系人
  • 已创建新联系人并选择发送邮件
  • 已创建新联系人并已发送优惠券
  • 现有联系人已订阅
  • 现有联系人已订阅并已发送优惠券
  • 等等..

所有这些情况基本上都是类别2xx OK,但是要触发不同的用户反馈信息,这就是为什么我不喜欢使用HTTP status codes。使用纯 HTTP 状态码并不能提供足够详细的反馈,并且定义 a) 额外的状态码或 b) 完全自定义的状态码感觉很随意。

那么,去这里的最佳做法是什么?

This answer 建议我应该始终使用标准的 HTTP 状态代码,如果它们不适用,那么我的设计是错误的。在客户端不使用额外的逻辑和 api 调用的情况下,如何区分差异?

【问题讨论】:

    标签: api http rest response


    【解决方案1】:

    HTTP 状态代码的目的是传达 HTTP 操作的状态 - 它是成功的、未授权的、未决的、配置错误的,等等。在您描述的所有情况下,请求的操作都是成功的 - 一切都按计划进行。因此,对于所有这些情况,最可能的状态代码是 200 OK 或 201 CREATED。

    不应将其他特定于域的状态强加到 HTTP 状态中。只需在您的回复中返回一个附加字段。例如:

    POST http://www.example.com/users
    {
        name : "The User",
        email : "email@theuser.com"
    }
    

    响应将包含:

    201 CREATED
    {
        status : "Optin mail sent",
        timestamp : "...",
        ...
    }
    

    这样可以更清晰地分离关注点并提高可扩展性。

    【讨论】:

      【解决方案2】:

      在客户端不使用额外的逻辑和 api 调用的情况下,我如何区分差异?

      使用有意义的响应正文。状态码就是这样。您不想为每个新的结果组合创建新的 HTTP 状态代码。

      所以对于你的前三个场景:

      HTTP/1.1 201 Created
      ...
      
      {
          contact_created: "true",
          optin_mail_sent: "true",
          coupon_sent: "true",
      }
      

      您需要以任何方式在客户端显示逻辑(例如,从254 ContactYesOptInNoCouponYes 到适当的通知),因此响应正文似乎是最明智和可扩展的方式。

      【讨论】:

        猜你喜欢
        • 2015-09-10
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2013-10-15
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多