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

我给出了一个关于讨论

HTTP方法

和

状态码

的常见用户登录/注销示例。我希望它能帮助人们容易理解

---

传统的非restful api设计：

当用户登录/注销网站时，一定要通过

POST

方法的HTTP请求访问后端服务

这是毋庸置疑的

---

但如果我遵循RESTfulAPI设计模式，它仍然可以设计吗

我的想法是：

• 登录

Login

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

201 Created

状态码吗

• 注销

相对而言，

Logout

将在用户发送令牌并注销时删除令牌密钥。我认为这是db的一个删除操作，因为删除了令牌密钥，所以它是否应该返回

204 No content

状态码

虽然我认为它可能符合HTTP方法的含义，但如果我提供或共享此API设计，是否会让其他开发人员感到困惑

---

我不知道这个主意好不好。我想听听您的意见。

我不认为您描述的场景会让开发人员感到困惑。根据我的经验，很少会有200、201或204左右的特殊处理，而典型的情况是

code>=200&&code<300

。你的逻辑并非不正确。如果您要返回令牌，则

201

是合理的，如果您不返回任何内容，则

204

是合理的

---

然而，生成令牌实际上是您登录的一个副作用

POST/login

不会创建

login

资源，就像

POST/items

会创建

item

，API令牌不是典型的资源。出于这个原因，

200ok

更合适，因为您实际上只是授予用户向前移动到受保护资源的权限，尽管是通过创建令牌。如果您环顾四周寻找身份验证示例，似乎发送

200

或重定向用户是典型的解决方案。

登录

和
注销
都应该是POST，因为GET在某些情况下可能会被缓存。
在注销成功时，服务器可能会设置响应状态302重定向和标题
位置：在注销后url\u to\u visit\u
这些生成令牌的行实际上是您登录standout的副作用-提醒API设计关注点的分离。