如何确定Rest API响应生命周期

时间:2016-06-04 17:05:21

标签: rest http express

我将使用NodeJS和Express框架开发一些REST API。用户API就是其中之一。但我很困惑,无法为API的每个场景发送正确的响应。发送响应HTTP状态的顺序如下:

GET / users HTTP / 1.1

  1. 400 Bad Request检查网址是否格式错误。
  2. 401 Unauthorized检查是否未提供访问令牌
  3. 403 Forbidden检查访问令牌中的用户是否不允许查看这些资源
  4. 200 OK如果不是,则找到一条或多条记录
  5. GET / users /:id HTTP / 1.1

    1. 400 Bad Request检查网址是否格式错误。
    2. 422 Unprocessable Entity检查ID是否未正确验证,例如非数字字符串
    3. 401 Unauthorized检查是否未提供访问令牌
    4. 403 Forbidden检查访问令牌中的用户是否不允许查看此实体
    5. 404 Not Found如果找不到请求
    6. 200 OK如果找到了正确的实体
    7. 500 Internal Server Error如果在实体查找期间MySQL或节点服务器端出现任何问题。
    8. POST / users HTTP / 1.1

      1. 415 Unsupported Media Type检查标头Content-Type是否不是application / json。
      2. 400 Bad Request检查JSON格式是否正确或是否存在语法错误
      3. 401 Unauthorized检查是否未提供访问令牌
      4. 403 Forbidden检查访问令牌中的用户是否不允许创建新实体
      5. 422 Unprocessable Request如果请求正文参数中的某些验证失败
      6. 409 Conflict Issue如果请求中的用户名或电子邮件不可用或已存在。
      7. 200 OK with new entity Location Header如果实体成功创建。
      8. 500 Internal Server Error如果在实体创建期间MySQL或节点服务器端存在任何问题。
      9. PUT / users /:id HTTP / 1.1

        1. 415 Unsupported Media Type检查标头Content-Type是否不是application / json。
        2. 400 Bad Request检查JSON格式是否正确或是否存在语法错误
        3. 422 Unprocessable Entity检查ID是否未正确验证,例如非数字字符串
        4. 401 Unauthorized检查是否未提供访问令牌
        5. 403 Forbidden检查访问令牌中的用户是否不允许更新此实体
        6. 422 Unprocessable Request如果请求正文参数中的某些验证失败
        7. 409 Conflict Issue如果请求中的用户名或电子邮件而不是此用户不可用或已存在。
        8. 204 OK with no content如果实体已成功更新。
        9. 500 Internal Server Error如果在实体更新期间MySQL或节点服务器端出现任何问题。
        10. DELETE / users /:id HTTP / 1.1

          1. 400 Bad Request检查网址是否格式错误。
          2. 422 Unprocessable Entity检查ID是否未正确验证,例如非数字字符串
          3. 401 Unauthorized检查是否未提供访问令牌
          4. 403 Forbidden检查访问令牌中的用户是否不允许删除此实体
          5. 404 Not Found如果找不到请求
          6. 204 OK with no content如果实体已成功删除
          7. 500 Internal Server Error如果在实体删除期间MySQL或节点服务器端出现任何问题
          8. 所以我想在Stackoverflow上讨论的是:

            1. 以上所有顺序步骤是否正确或需要再次思考?
            2. 在任何可能导致最终用户看到非JSON响应的情况下,此API是否会中断?

1 个答案:

答案 0 :(得分:1)

以上所有状态代码现在都很好,除了Twitter在记录HTTP状态代码和其他问题的特定错误代码方面做得很好。有些绑定到HTTP状态代码,这很好,但很多都没有。有些还与相同的状态代码绑定,突出显示上面提出的问题。请查看以下文档。

Error Codes & Responses

希望这有帮助。