【问题标题】:How To Decide Rest API Response Life Cycle如何决定 Rest API 响应生命周期
【发布时间】:2016-06-04 17:05:20
【问题描述】:

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

GET /users HTTP/1.1

  1. 400 Bad Request 检查 URL 是否格式错误。
  2. 401 Unauthorized检查是否没有提供访问令牌
  3. 403 Forbidden检查访问令牌中的用户是否不允许查看这些资源
  4. 200 OK如果没有,找到一条或多条记录

GET /users/:id HTTP/1.1

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

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 或 Node 服务器端出现任何问题。

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 或 Node 服务器端出现任何问题。

删除 /users/:id HTTP/1.1

  1. 400 Bad Request 检查 URL 是否格式错误。
  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 或 Node 服务器端出现任何问题

所以我想在 Stackoverflow 上讨论的是:

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

【问题讨论】:

  • 这不是讨论的论坛。编写并测试它应该可以回答您的问题,所以这样做
  • 我知道,但我想知道正确的方法。
  • 你知道并写了它吗? 那更糟!

标签: rest http express


【解决方案1】:

除了 Twitter 在记录 HTTP 状态代码和为其他问题提供特定错误代码方面做得很好之外,现在所有状态代码都很好。有些与 HTTP 状态代码相关联,这很好,但很多不是。有些还与相同的状态代码相关联,突出了上面提出的问题。请查看下面的此文档。

Error Codes & Responses

希望这会有所帮助。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-09-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-05-29
    • 2022-11-06
    • 1970-01-01
    相关资源
    最近更新 更多