Statelessness

依据REST架构，服务端不应当存储任何客户端session以及其他客户端状态信息。这个限制就叫做无状态（Statelessness）。从客户端发送到服务端的每一个请求必需包含服务端理解请求所需的全部信息，并且不能使用任何存储在服务端的上下文。session状态必需全部存储于客户端。客户端负责存储和维护所有的应用程序状态信息。

这同样意味着客户端需要向服务端发送所有状态信息，不管服务端是不是都用得上。同时不应当在服务端和session之间存在任何关联。

无状态意味着每个HTTP请求都是完全独立的。当客户端发送一个HTTP请求时，它应当包括服务端处理请求所需的所有的信息。服务端绝不依赖于任何之前的请求所包含的信息。如果（之前的请求所包含的）信息足够重要的话，客户端应当将其打包至当前请求中再发送一遍。

为了确保客户端可以使用这些无状态的API，服务端返回数据时，应当告知客户端需要创建哪些状态。

为了保持无状态，不要在服务端存储任何客户端的认证和授权信息，要在客户端发送的API请求中附带这些授权凭证。每一个请求必需保持独立并不受当前客户端之前会话的影响。

Application State vs Resource State

请不要将应用程序状态和资源状态弄混了，这是两个截然不同的概念。

应用程序状态是服务端的一小段数据用来识别收到的客户端请求，存储预先的交互信息以及当前的上下文。

资源状态是在某个时间点上的服务端的资源的状态，这与服务端与客户端两者之间的交互无关。这是你在API响应中获取的内容，同样也称为资源的表现层。

REST所描述的无状态指的是没有应用程序状态。

Advantages of Statelessness

对于无状态的REST API有许多值得一提的优点如下:

1. 无状态可以使API轻易地部署到多个服务器上从而应对数以百万的并发用户数。每个服务器都可以处理相关的请求，因为没有session的依赖。
2. 无状态可以通过移除服务端的状态状态同步机制使REST API的开发变得相对简单。
3. 无状态的API响应更容易被缓存，客户端可以通过查看该请求信息来决定是否缓存一个HTTP请求的结果。之前请求的一个状态并不会影响到当前请求是否可缓存。缓存可以提升服务端的性能。
4. 服务端永远不会丢失每个客户端在当前应用程序中的状态信息，因为所有必要的这些状态信息都包含在了请求里面。

译者注：

此处可以使用JWT(Json Web Token)来实现，将必要的状态信息在服务端加密后存储在客户端里，客户端每次请求都会将这些必要的状态信息发送至服务端，服务端随即解密获取相关信息。