cyl19910101

@jokester 好的，不再强拉到一块儿想，感谢感谢

@realityone 见识过，130个字符一行的iterm2居然一行放不下。。。。。。但是我还没做过大的有压力测试的东西，心里面对于一个请求的耗费容忍度没太大概念，之前总是感觉字符串的东西，撑死了也大不到哪儿去。。。。

@kslr 感谢感谢，新浪那篇提了一些历史上http这么设计的原因和应用中我们对这种设计结合自己的需求做出的解决方案还是比较扩充知识的，感谢！

@binux
嗯，感谢解释，确实还是以两个请求之间是否相互影响为根本判别。从两个角度看客户端登录这个说法比较有意思，玩味一下。

@jokester 感谢解答，感觉这个说法有点新奇，因为我上网络课的时候介绍的无状态特性是指出两个请求之间互相独立，一个请求不会对另一个请求产生影响，有一点像这篇的表达： http://blog.csdn.net/tennysonsky/article/details/44562435
您的意思是REST里面讨论的无状态是指Token的不可变更性，而session机制里面的随请求时时更新状态（过期时间，登入登出等）就违背了这个要求是吗？

@kslr 嗯，说实话那也是一个让我产生疑惑的讨论，当初看那个讨论的时候，大家围绕几个点说，我大概揣摩的是这样几个意见：
第一个就是您说的那个，session设计是和cookie相结合的，现在我们不用session了，所以设计个token来解决这个需求，所以其实是应景而生的类似的东西。这里面让我疑惑的就是基于这个需求设计出来的token机制，为什么就可以说自己是stateless而session却不是。
另外一个感觉比较有针对性的观点就是akfish说的那个“Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端”，这个可以说是一个很有力的理由说明token是stateless的，只需要解析token就能进行验证，服务器不需要存，这一切看起来就特别顺理成章了，直到我看到上面提到的第二个链接里面说到验证之后还是需要存到缓存（他建议用redis）中去，等到请求过来的时候进行校验，那这个样子还是一样要存这些用户信息在服务器上，并没有感觉和session的做法有根本上的差异。
所以感觉就是不明白到底token体系这一系列流程中，哪个关键点和session体系是截然不同的而导致它可以被称之为stateless。akfish给的资料相当有用，但是感觉离说服大家“token是无状态而session是有状态”还差一个关键的说明，而这个说明也是我一直找不到的，网上也有不少人像王垠说的就给一句“ RTFM”，让自己去看cookie和session，而Manual中没有作出很强力的证明，需要一些关键提点的地方，他们也不愿意给~
非常感谢您的回答，感觉咱们对token的设计意图理解有点共识，我就是还没找出它和session机制之间一个敢说自己是无状态而另一个并不是的理由，您要是知道这里面的原因还望帮帮忙

@binux token肯定是要带在请求上的，我上面其实没有说不用发。。。。。我是看不出在服务器存储上用session还是用token的方式在“是否无状态”上的差异。确实是有点纠结概念，主要是因为看REST一直坚持无状态才能叫REST，然后大家应用上面还是在服务器上存储了token这样一个记录，所以没看出来两者之间的本质区别，就不知道凭什么说不记录session而记录token的方式就能满足它所说的无状态