Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

遇到 401 状态码就让用户去登录的设计并不好

  在以前的项目中,对于用户鉴权这块的接口设计,我尝试过使用 401 状态码表示用户需要登录,并且前端全局地拦截这个状态码,让用户去登录。也就是说,无论哪个 API 调用,一旦遇到 401 状态码前端就会引导用户去登录。当时觉得这个设计逼格很高,现在看来也是满地的坑。
  为什么把一个状态码和前端的行为绑定在一起?为什么针对 401 而不是其它状态码?其实这里的逻辑就有点问题,当时只是为了便于前端统一处理而做了这样的设计。把登录需求全交给 API 控制,前端不需要在每一块业务代码中做一个同样的逻辑处理,从而减少大家的工作量。假如把 400 状态码也做一个统一处理会怎么样?显然是不行的,因为 400 可能是各种不同形式的错误,具体描述在响应的实体中。和 400 比起来,401 只是一种描述比较确切的情况,大部分情况下不需要根据响应实体来处理而已。而「描述比较确切」是一个主观的判断,只是大部分业务场景下是如此而已。在一些特殊的业务场景中,比如服务器具有多套授权机制,那么这么做就需要解析响应实体做出不同的处理,或者根据 401 发生的 URL 不同做出不同的处理。
  另一方面,把「响应 401 状态码前端就会引导用户去登录」这件事同步给后端开发人员也是一件痛苦的事情。特别是在大项目中,后端会拆分成多个服务,也就是一个前端会对应多个后端服务。而且这些后端服务可能由不同的团队维护,甚至使用不同的编程语言开发。这就大大增加了沟通成本。
  与其如此生硬的逻辑不如根据一个自定义的响应头或者定义一个通用的响应实体来描述一些通用的操作?目前我是这么认为的。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^