@wzwb 大家公认的 Authentication: Basic username:password 这种是 RESTful 的，这种没去根据用户名和密码查询么？为了不在每次请求中都传输账户和密码，所以发明了令牌代替用户名和密码来做认证，所以有啥问题？

你能试着先把会话那一套东西忘掉么，要不然就没办法聊了，每说两三句，你的思路就回到会话那边去了。

@wzwb 你自己到底要用服务端会话还是不用？如果你选择不用，那你说的由服务器返回历史数据从何谈起？如果你选择用服务端会话，那就没啥要讨论的了。

在用户做选择的时候一个请求发给服务端，告诉服务端客户选了哪个角色当作自己的全局默认角色不就可以了，服务端把这种角色保存起来就可以了，而且这种数据也不应该保存在服务端会话中，这应该保存在数据库中吧。

@ZSeptember JWT 里面就一个用户标识和过期时间，然后存在客户端本地存储，用户当前所选的角色也存在客户端本地存储，每次向服务端发送请求，直接把 JWT 放在 Authentication 头中，把当前所选的角色放在请求参数或者主题中即可。如果有人把客户端选的角色删了，本次请求也验证不过啊，返回一个业务状态码就能和客户端说清楚了啊，所以有什么好担心的呢？

在服务端看来所谓的登陆就是创建一个令牌资源，令牌资源能创建，当然就该保存，当然也就能删除。服务端颁发 JWT 后，它确实能通过防篡改、伪造的检查，但 JWT 只不过是一个壳，真正重要的是 payload 里面的 jwt id，它可以用来识别用户，也可以被回收。

@wzwb 发起确实是用户发起，然后告知客户端，然后客户端发给服务端，然后服务端生成会话数据，然后发回到客户端保存，然后下次客户端再自动发回给服务端。第四句就是生成，然后你不觉得第三句到第五句是在兜圈子么？客户端都知道用户在交互中的选择了，干嘛还要发给服务端，直接自己保存不好么，然后每次请求都发给服务端，服务端直接用不就成了。

@ZSeptember 我这里不是说 token 啊，做认证的 token 当然在服务端生成，这没毛病。但是交互过程中又不仅仅登陆这一种“状态”，还有各种交互状态，很多人说把这些状态全部丢到客户端，就比如直接丢到 JWT 中。

还是拿我上面举过的例子来说吧。

比如，我有一个账户，即属于运营人员角色，又属于某种管理人员角色，但运行时角色只能二选一，即角色运行时互斥。比如服务端通过一个接口返回可选的角色，客户端把这些角色展现给用户，然后用户选择某个角色，客户端再把用户的选择（即所谓的“状态”）保存在客户端本地存储中，后面每次请求带上该角色（状态）即可。

注意，这个状态可不是服务端在服务端代码里面生成，然后再丢到响应头或者主体里面返回给客户端的，就是地地道道客户端自己生成并保存到客户端本地存储中的。你能说这种有问题么？再者服务端当然不会信客户端的数据啊，但是服务端本来就该做验证啊，比如验证用户是谁，存不存在，权限够不够等等，客户端发篡改的数据过来，服务端验证也过不了。

@lihongming 你说到 AWS 的情况，我猜测可能是 AWS 引入了 RBAC 模型，并且角色与会话绑定了，才会引发不得不这么做。

比如，我有一个账户，即属于运营人员角色，又属于某种管理人员角色，但运行时角色只能二选一，即角色运行时互斥，那就要这么做了。此时，如果我有两个浏览器，都用这个账号登陆，一个浏览器登陆后选择运营人员，一个浏览器登陆后选择管理人员，那用这种把 JWT 当作客户端会话的方法就很合适。

但是反过来，不在 JWT 中放入角色，也可以轻松实现同样的目的。比如服务端通过一个接口返回可选的角色，客户端展现，然后用户选择，客户端再把用户的选择（即所谓的“状态”）保存在客户端本地存储中，后面每次请求带上该角色（状态）即可。

这两种方法，都把状态存在了客户端而不是服务端，这是是没问题的。但区别是一个是服务端发起的保存和读取操作，另外一个是客户端自己发起保存和读取操作。很类似，但我个人确实觉得服务端发起和保存和读取操作，比较别扭，可能是我思维有点固化，没转变过来吧。

@libook 我和你的观点整体上是类似的。

@icyalala 我没有否定，也不敢轻易否定，但是确实有质疑，质疑一下没毛病吧。

@acmore 状态放在客户端没毛病，但是状态不应该“由服务端生成，然后放在客户端”，应该“由客户端生成，然后放在客户端”。

@kop1989 我当然知道要有状态，我也知道放在服务端不对，应该放在客户端，但是我觉得这些状态不应该由服务端生成和读取，应该由客户端自己生成本次交互过程的状态并存在本地存储，然后客户端发起请求时，从本地存储中取出来直接告知服务端，而不是“我把交互状态都发给你了，你自己看着选用吧”。

@msg7086 那就是了，完全是服务端在把控的东西（只不过存在客户端），还能说服务端“无状态”么？

@msg7086 你说的我基本上都明白，但我的意思是“状态”不应该由服务端生成（做决定），服务端每次只返回数据给客户端就可以了（服务端根本不在乎之前请求发生过什么），客户端接收到数据之后，要自己决定要把什么“状态”缓存在客户端本地缓存中，然后下次发起 api 调用时，自己决定该从客户端本地存储中读取哪些必须数据并和请求一起发给服务端。不是服务端决定该把什么“状态”缓存在客户端。

@kop1989 问题就是，现在我认为在 REST 下，两次请求就不应该用会话这个概念来贯通，应该是是毫无关系才对。

@wangritian 我现在认为如果要遵循 REST，会话数据就不应该由服务端生成，然后放在客户端，然后还绞尽脑汁想着怎么才能不泄露、篡改、伪造和重放。

@fengchang 我只是觉得，客户端会话的状态是有服务端生成，最后也是由服务端读取使用，这种不能算“无状态”。

我觉得客户端自主生成状态，然后放在自己的本地存储中，然后再根据下次调用的 api 需要什么数据，再从本地存储中取出来，这才是“无状态”，服务端根本就不知道“状态”为何物，只知道客户端会把我要的数据都发给我，我直接用就行了。

服务端不知道“状态”为何物 != 服务端不在乎“状态”存在哪里。

@Bromine0x23 这两段实际上我都看了，只不过觉得意思是一样的，所以我就引用了一段。所以你的意思是把交互状态放到“客户端会话”中算是“无状态”了？

@ysc3839 那就是说，你认为只要服务端无会话状态，比如把会话状态存在客户端，就算 REST 的“无状态”了，对么？

我个人的想法是，这些会话数据由服务端产生，最终也是由服务端读取使用，本质上还是服务端在用，只不过被存放在客户端上了而已。

如果客户端自己把交互过程中的状态存在自己的本地存储上，然后在向服务端发送请求时，自己从本地存储中选用服务端需要的状态，再和请求一起发给服务端，这才是真正的“无状态”。客户端自己存放，自己选取使用，服务端只做接收方。

@lihongming 你说的这种用法，如果只是登陆状态这一种状态，我觉得没问题，但是如果把 token 中塞满以前保存在服务端会话中的那些会话数据呢？就比如说用户权限数据，以前经常是保存在服务端会话中的，如果现在把它挪到客户端合适么？

@airfling 嗯，这个肯定没错，不过有些人认为还可以把比如用户 id 、用户权限等会话数据放到 token 中，虽然很方便，但这时候 token 就变成客户端会话了，我觉得这种做法不合适。