REST架构设计是目前非常火热的概念，已经成为构建web服务时应该遵循的事实标准。REST约束中有一条很重要的规则是“无状态”，但“无状态”是个很抽象的概念，对刚刚接触的人来讲，很难深刻形象的理解。今天在网上看了一篇文章，对于“无状态”的解释感觉很容易让人理解，特把文章中相关内容整理了下。

• "状态"的概念是什么

  一个Web应用程序协议的“状态”在通常指的是为两个相互关联的用户交互操作保留的某种公共信息，它们常常被用来存储工作流或用户状态信息等数据。这些信息可以被指定不同的作用域如page，request，session或全局作用域，而存储他们的责任也同样可以由Client端或Server端负责。

  服务调用过程中有两种“状态”：应用状态(Application State)和资源状态(Resource State)。应用状态指的是与某一特定请求相关的状态信息，而资源状态则反映了某一存储在服务器端资源在某一时刻的特定状态，该状态不会因为用户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现（Representation）。RESTful架构要求服务器端不保有任何与特定HTTP请求相关的资源，所以应用状态必须由请求方在请求过程中提供。

  例如session ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session ID被认为是unRESTful的做法。而用户的身份凭证信息作为一种应用状态，是被期望由请求方提供的，所以在请求中传递用户的身份凭证信息是符合RESTful架构规范的。

• 为什么要使用无状态的架构

  虽然存储状态为企业软件开发带来了诸多便利，但是它也给分布式系统的其他方面带来了许多限制，比如在负载均衡方面，在有状态的模式下，一个用户的请求必须被提交到保存有其相关状态信息的服务器上，否则这些请求可能无法被理解，这也就意味着在此模式下服务器端无法对用户请求进行*调度。于此相关的另一个问题是容错性，倘若保有用户信息的服务器宕机，那么该用户最近的所有交互操作将无法被透明地移送至备用服务器上，除非该服务器时刻与主服务器同步全部用户的状态信息。此外，由于HTTP本身不是一个有状态的协议，开发人员必须通过模拟实现状态的钝化与激活等。于是为了克服这些不足，无状态(Statelessness)架构风格属性受到了广泛关注。

• 无状态即各自维护自身的状态，如会话信息都在客户端，服务端并不保存状态信息，那么我们可以说服务端是无状态的，这个的好处是显而易见的，无状态的部分可以很方便的被替换掉（或集群、横向扩展）而不用状态重建（或同步），大大提高了可申缩性(scalability);通常J2EE的session被认是不好的设计，大部份J2EE中间件在集群时都需要进行session同步，而Play!并非基于J2EE体系设计的，则没有该烦恼！