@蛙蛙王子 谢谢你的关注，的确有些业务需求硬要用无状态方式去设计会觉得别扭，比如国外有些文章介绍如何去用REST设计一个事务，稍微看了以后我个人觉得，哪怕这个设计的确实现了需要的功能，但它降低了代码的可读性，后续开发人员需要重新去习惯另一种思维方式，而相比较来说用有状态方式去设计在理解上会更自然。 对于你举的QQ会话的例子，用REST模式去架构的话，会把A与B之间的会话作为一个资源并分配一个URL，他们之间的消息会通过对这个URL的POST操作完成，当然这需要一些额外的权限功能，比如只允许A和B对这个URL进行POST等。这样的话A与B不需要知道他们的会话在那一台服务器，因为WEB服务器将负责将对某个URL的请求发送至相应的应用服务器处理。 所以我在这里想说的是可能很多有状态的设计都能转化为无状态的设计，但并不一定非要做这样的转换，一切都应该视项目需求和团队成员来决定。

其实也就是HTTP这种短连接的服务才有这个问题，如果是TCP长连接，第一次建立连接时用随机负载，随便路由到哪台机器都行，完了这台机器即使是有状态的也没事，反正长连接已经建立起来了，后面的请求都会到这台机器上，无非耗费点儿服务器内存，不影响服务的可伸缩性。 当然宕机了还是没办法，用别的办法去弥补只能。

这篇写的很好。

讲的我看明白了,不过我觉得一个服务是有状态的还是无状态的,是由这个服务的逻辑来决定的,不是你想让它无状态就无状态了吧。 当然，尽量发挥客户端的功能，可以提高服务端的性能和可伸缩性，但一个URL里才能保存多少状态。 另外有些服务，如果服务端不保存状态，后面有服务过来的通知，这个服务没有状态，就没法处理这个通知。 再举个例子，QQ的会话服务器吧，A和B都登录到一个会话服务器上，A说话，B能看见，B说话，A能看见。如果A说第一句话和第二句话到不同的服务器上，B就不可能看到了，这样的服务器没法设计成无状态的，只能在服务前加7层负载，或者其它软负载的方法来解决扩展性。 可能我对无状态服务设计经验太少，请多多指教。

非常感谢楼主...

楼主理论水平很不错啊，没人顶真可惜。

up

大哥 能好好排版一下吗？

@James.Ying
接下来的几篇里我会分享一下对基于HTTP和URL的REST中属性的认识，也会包含对状态的讨论。另外我过去的一篇随笔里也发表了一点对REST中状态的看法，谢谢您的关注。

@Nyyrikki
非常感谢楼主的解答，我现在有点明白了，期待你下篇能说说这个状态，非常的期待

@James.Ying
恩，我觉得您考虑的过于深入了，从OSI模型上讲REST属于应用层的架构，而TCP是传输层协议。关于TCP的状态，我想您指的是SYN，SYN-ACK这类吧？它们指是两个通信终端的连接状态，是每次通信的建立所必需的，而与通信中传输的消息状态无关。举例来说吧，我们到邮局寄信时，信件会被暂时放在一个发送队列里，这时它处于“等待状态”，但是这个状态和我们用什么样式的信纸，用中文还是英文写信无关。REST中的无状态指的是资源状态，而它与连接状态的关系就与这个例子中类似。REST提出了对应用层的一组需求，但它并没有对传输层要求什么，传输协议也完全可以用TCP以外的协议。例子有点生硬，不知有没有解答您的疑惑。

@Nyyrikki
我不是很懂，只能说个大概，有状态因为它是tcp连接，客户端和服务器端必须建立连接，既然已经连接必然有一个状态存在，不知道是否是这样

@James.Ying
GET请求实现了REST中资源状态表述的转移，属于实现层面，而REST是一组需求的集合，为了满足这组需求，通过HTTP和URL实现的REST使用GET请求来获取资源的表述。
您可不可以说一下你对状态的理解？为什么你会觉得REST不是无状态的？谢谢

其实我非常想知道Rest和一般的Get请求由什么区别,大家都说有状态和无状态,但我发觉Rest不是无状态,也是一个Get请求,那肯定是有状态的,文章我也没看完,因为我发觉现在更迷茫了.

太长了，看不下去。

@刘晓飞
谢谢你的建议，因为我希望解释那些被简化了的概念

建议LZ写的精短一点，这么些看起来实在有些乏味。。

@老姜
“传参数”是面向服务的思维方式，REST是面向资源的，Url整个就是资源的标识符。

up

@Todd Wei
谢谢你的关注，其实我发了那篇关于无状态的讨论后稍微查了下园子里对REST的讨论，觉得有些概念上的问题还是有点出入的，至少和我浅薄的理解有点出入，所以目前在筹划一个关于REST的系列，大概本周末或下周POST第一篇吧，不要吝啬您的批评和看法哟。