如何定义登录和注销的HTTP方法和状态码？

Posted 2023-02-25

【中文标题】如何定义登录和注销的HTTP方法和状态码？

【英文标题】：How to define HTTP method and status code of Login and Logout?

【发布时间】：2016-01-22 12:31:34

【问题描述】：

我给出了一个关于讨论HTTP method 和status code 的常见用户登录/注销示例。我希望它可以帮助人们轻松理解。

---

传统的无restful api设计：

当用户登录/注销一个网站时，一定会通过POST方法的HTTP请求访问后端服务。

这是毫无疑问的。

---

但是如果我遵循restful api设计模式，那还设计吗？

我的想法是：

登录

Login 将在用户登录时生成一个令牌密钥。我认为这是对数据库的创建操作，因为生成了令牌密钥，所以它应该返回201 Created 状态码吗？

退出

相对地，Logout 将在用户发送他的令牌并注销时删除令牌密钥。我认为这是对 db 的删除操作，因为删除了令牌密钥，所以它应该返回204 No content 状态码吗？

虽然我认为它可能符合 HTTP 方法的含义，但如果我提供或分享这个 API 设计，会不会让其他开发者感到困惑？

我不知道这个想法好不好。我想听听你的意见。

【参考方案1】：

login 和 logout 都应该是 POST，因为 GET 在某些情况下可能会被缓存。 在注销成功服务器可能会设置响应状态 302 重定向和标头location: url_to_visit_after_logout

【参考方案2】：

我认为您描述的场景不会让开发人员感到困惑。根据我的经验，您很少会在 200、201 或 204 附近进行特殊处理，而典型情况是 code >= 200 && code < 300。你的逻辑并没有错。如果你要返回一个令牌，201 是合理的，如果你不返回任何内容，204 是合理的。

但是，生成令牌实际上是您登录的副作用。POST /login 不会创建 login 资源，如 POST /items 将创建 item，并且 API 令牌不是典型的资源。出于这个原因，200 OK 会更合适，因为您实际上只是授予用户前进到受保护资源的权限，尽管是通过创建令牌。如果您四处寻找身份验证示例，似乎发送200 或重定向用户是典型的解决方案。

【讨论】：

这些行生成令牌确实是您登录的副作用 突出 - 提醒 API 设计的关注点分离。