Web 技术研究所

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

关于是否使用 Cookie 的纠结点

  前段时间我曾一度想要弃用 Cookie。总觉得 Cookie 很笨拙,而且会有一大堆跨域的坑。还是相对干净的无状态 API 好用。但用虽好用,它的坑也不少。而到后来「状态」是什么也值得思考了,用户登录状态是一个「状态」么?既然是有状态那为什么又用无状态 API ?

有状态和无状态 API 的特点

  无状态 API 的好处是每个 API 都相对独立,耦合度低。而有状态 API 中可能包含「某个请求需要先执行一次另一个请求后才能生效」这样生硬的逻辑,比如要先执行登录操作之后修改个人信息的操作才能成功。虽然逻辑生硬,但确实有时候有状态的 API 会比无状态的方便。比如修改个人信息这个业务,无状态 API 不仅要传递个人信息数据,还要传递登录状态数据。而有状态的 API 由于登录状态是 Cookie 管理的,只要考虑个人信息数据即可。

我为何不爱「有状态 API」?

  我以前曾纠结过一个很无聊的问题「将登录状态记录在 Cookie 中,很多用不到登录状态的 API 调用时 Cookie 也会传递,造成通信资源的浪费」。其实一个 SessionID 还不到 100 字节,所谓通信资源浪费纯粹是我这种有精神洁癖的人意淫出来的东西。这个理由完全不足以动摇 Cookie 的地位。
  但除了这个理由外,还有很多原因。比如跨域就是个很严重的问题。IE8 的 CORS 无法跨域传输 Cookie,如果 API 服务器是在一个子域上的话就要挂。而且 Cookie 的名字实际上就是一个全局变量的概念,如果大家都使用 Cookie 就可能会造成冲突。
  另外,即使是有状态的 API,也需要本地储存用户的登陆状态,以让用户在第一时间看到自己的登陆状态。这是无状态 API 本来就做了的事情。既然总是要将用户信息储存到本地,那为何不直接使用无状态的 API 呢?

App 开发的启示

  前段时间听 App 开发组的人抱怨版本发布太痛苦,突然觉得有些东西确实也该思考一下。Web 程序的版本发布基本上是半强制性的,很容易就可以升上去,而 App 每次发布新版本都要让客户端升级,而且升级总是无法 100% 覆盖。无法升级就意味着无法修改客户端代码,那么要增加功能怎么办?如果是无状态 API,增加新功能就必须修改接口调用参数吧?但如果是有状态 API 就不同,有时候无需修改客户端代码,调整接口含义就行。Cookie 有个神奇的地方就是服务器对 Cookie 是可读写的。在客户端代码无法更改的情况下,服务器端更新程序来管理 Cookie 就是一种比较好的做法。

纠结的彼岸

  其实说了半天,我依然还是无状态 API 的忠实拥护者。但如果一些特殊情况的话,比如服务器程序是 App 和 Web 通用的话,那体谅一下 App 那边的苦衷,使用有状态 API 也是可以接受的。毕竟 Web 也曾经是这么走过来的。

网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^