（备注：本文由本人翻译自Ruben Verborgh的rest, where’s my state?）

下面为正文内容：

超文本传输协议HTTP是在REST架构风格约束下被设计的。而这种具有代表性的状态传输风格的一个众所周知的特点就是在数据通信时必须是无状态的。那么，为什么会引入这样特殊的限制？并且由哪方来维护这个对于大多数Web应用程序显然很必要的状态变化？这篇文章将给你答案，它将解释现代的Web应用程序是无状态的运行，并且说明了应用状态和资源状态的不同。

HTTP协议1.1规范的主要作者Roy T. Fielding，在他的博士论文中用了整个章节来描述了“REST架构风格”。REST构成了HTTP协议的基础，而每天我们都在使用HTTP协议来浏览各式的网页。当Roy T. Fielding在追溯REST架构风格的基本属性时，“无状态”按照时间顺序被列在了第二位，仅仅排在前后端分离（client-server）的后面。因此，毫无疑问，“无状态”约束对互联网的成长和成功至关重要。

而理解这个“无状态”的关键是要理解两种不同类型的状态（应用状态和资源状态）。

“无状态”让服务端不必记录

这里的“无状态”的概念是从服务端的角度来定义的，它规定了服务端不应该保存应用程序的状态。因此产生的影响是，客户端必须在每次请求时发送全部的信息给服务端，因为服务端没有保存任何信息内容，所以根本无法从之前的请求中重用一些信息。

具体来说，这意味着，比如你正在浏览一个图片集而且正在看服务端返回的23号图片，当你要看下一张时不能仅仅跟服务端说“下一张”，而是要跟服务端说“第24号图片”。很明显，客户端必须在请求中提供全部的信息，因为服务端是“无状态”的，它可不知道你正在浏览第23号图片。

不过幸运的是，你在客户端也不必知道你真正浏览这个特定的图片（如第23号）。因为服务端在你获取这个图片时，完全可以将“上一张”和“下一张”的链接返回给你，以链接到正确的图片地址。那么这不与刚刚说的“无状态”矛盾么？不，这并不矛盾：在服务端正在生成这个第23号图片的返回时，表明服务端正在处理你的“获取第23号图片”的请求，在这个特定的请求下服务端是有足够信息知道第23号图片的“上一张”和“下一张”图片分别是哪张的。

服务端将一种资源通过某种特定形式（如链接地址）返回，并用于引导了客户端的下一步操作，我们把这种特定形式称之为超媒体。（译者：Hypermedia实际是扩展了超文本,超媒体是一个非线性介质的信息包括图形、音频、视频、文本和超链接。）得益于超媒体，服务端不必记录Web应用程序的状态。此外，客户端也不需要事先知道他们后面可以执行什么操作，因为一些的信息都包含在了超媒体信息中。

“无状态”造就了Web（全球广域网）的大规模

Fielding指出了“无状态”带来的三个重要特性：

• 可见性：每个请求都包含了需要解析的全部内容。因此，单单看一个请求就足以将交互可视化。
• 可靠性：每个请求都是独立的，一个请求的失败不会影响到其他的请求。
• 可扩展性：服务端不必记住每个应用的状态，这利于服务端在更短的时间内响应更多的请求。

其中可扩展性已被证明是非常重要的：人类创建了最大的互联网络就是Web（全球广域网），而Web正是基于REST架构风格约束的HTTP协议构建的。

客户端处理应用状态，服务端则处理资源状态

或许你现在很想知道，究竟我们是怎么在互联网上发布一段内容的。因为很明显的, 当你发一条微信, 微信服务器上肯定是会有所变化的，所以我们还是感觉这其中必然是有某种形式的服务器状态存在的。那么要想从“无状态”的角度理解这个过程，首先我们必须看到有两种状态的存在。一种是应用状态，也就是之前一直在讨论的“不保存”的状态；另外一种是资源状态，而这种状态正是服务端在处理的。

应用状态是用于保存交互中的相关信息，它被用于你的应用程序会话期间。例如，你正在浏览第23号图片，你已经登录了微信，这些事实情况都是应用状态。通过超媒体来控制就可以改变这种应用状态。如在微信中点击短视频就进入视频播放（超媒体表现为一个视频的链接地址；应用状态变为正在浏览视频）；如在微信中超媒体可能还表现为声音或按钮，按住录制声音、松开发送语音等。

而资源状态则是一种由服务端存储的（半）永久数据，它并不仅仅临时存在于某个单一会话中。你微博中上传的一个图片和发表的一篇微博内容都是资源状态的示例。所以，你可以看到，虽然HTTP是一种无状态的协议，但是你依然可以在服务端长期保存某种状态（资源状态）。但是，保持交互会话中使用的短期状态（应用状态）则是客户端的责任，这个状态必须在每次请求中发送。正是这使得Web成为“无状态”，并且是其发挥可扩展性的关键。

（译文完毕！）