推荐一篇博文 ，这个介绍的很详细，很好理解（点击跳转）
"Statelessness" 是restful风格最重要的原则。
它的含义是指，客户端和服务器交互的过程中（各次请求之间）是无状态的。
无状态通信要求在网络通信过程中，任意一个Web请求必须与其他请求隔离，当请求端提出请求时，
请求本身包含了响应端为响应这一请求所需的全部信息。
一个WEB应用协议中的“状态”指的是，为两个相互关联的用户交互操作保留某种公共信息，例如用户登录信息，工作流等。 这些信息具有不同作用域，如page，request，session，application等。通常由服务器负责保存这些信息。 无状态是针对于“状态”来说的,“无状态” 概念的逐渐流行，得益于分布式系统的发展。 首先，无状态请求易于实现负载均衡。在分布式web系统下，有多个可用服务器，每个服务器都可以处理客户端请求。 传统的有状态请求，因为状态信息只保存在第一次发起请求的那台服务器上，之后的请求都只能由这台服务器来处理， 服务器无法自由调度请求。无状态请求(就是一个全新的不同的请求)则完全没有这个限制。 其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地(用户不会感觉出服务器的变换)交由另一台可用服务器来处理， 而有状态的请求则会因为存储请求状态信息的服务器宕机而承担状态丢失的风险。 需要注意的是，“状态"指请求的状态，而不是资源的状态。Restful风格的无状态约束要求服务器不保存请求状态， 如果确实需要维持用户状态，也应由客户端负责。 无状态 : 客户端对服务器端的请求应该是无状态的，请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态(检查是否有之前请求的参数状态等)。 无状态约束使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户端并不依赖于同一台服务器以下摘自csdn,方便理解无状态 : 举例子： 状态记录在服务端设计： a, 用户user登陆后，user的上下文信息例如记录该user已登陆的标识保存在服务器端session中，当用户发生下一次的请求，服务端会根据userId查找该session是否标记了该用户已登录的状态 b, 用户浏览书签页，当前用户浏览的页面是第3页，这个第3页的信息保存在服务器端session中，当用户请求下一页nextPage，服务端从session拿出当前阅读状态为第3页，基于此状态计算出下一页是第4页 RESTful的设计： a, 用户user登陆后，服务器生成验证信息token，该token标记该用户已经登陆的状态，服务端不保存该token信息，而是token返回给客户端， 当用户发生下一次的请求，客户端把该token重新发送给服务端，于是服务端就根据该token知道用户已经登陆的状态(具体实现是：第一次登陆，token信息在数据库端缓存下来，第二次请求时候从数据库缓存查询该用户token。这样用户状态的信息就不需要保存在服务器端，保存了在数据库端，数据库端一般采用redis类型的缓存数据库) b, 用户浏览书签页，当前用户浏览的页面是第3页，服务器返回当前页第3页这个状态给客户端，服务端不保存当前阅读页数的状态，当用户发生下一页的请求，客户端把当前页第3页和下一页操作给服务端，服务端基于客户端的状态信息计算出下一页是第4页 由此可以看出， REST 风格应用可以实现交互，但它却天然地具有服务器无状态的特征。在状态迁移的过程中，服务器不需要记录任何 Session，所有的状态都通过 URI 的形式记录在了客户端。更准确地说，这里的无状态服务器，是指服务器不保存会话状态(Session)；而资源本身则是天然的状态，通常是需要被保存的；这里所指无状态服务器均指无会话状态服务器。补充一点： REST表述性状态转移，个人认为可以简单理解为把服务端的状态迁移到客户端保存或者数据库端保存，从而应用服务器就可以设计成无状态。严格来说应该是“准确理解REST在应用服务端的无状态设计”。