无状态服务器

    REST风格应用可以实现交互，但它却天然地具有服务器无状态的特征。在状态迁移的过程中，服务器不需要记录任何Session，所有的状态都通过url的形式记录在了客户端。PS:更准确地说，这里的无状态服务器，是指服务器不保存会话状态(Session)；而资源本身则是天然的状态，通常是需要被保存的；本文提到的无状态服务器均指无会话状态服务器。

    举个例子：一个心理测试的应用，需要用户做2次选择题，每次可选A、B两种答案，2次选择完毕之后将告知用户属于何种心理类型。

    如果按ORB或SOA的服务思维，很容易想到在服务器端保存Session，每次选择以后修改Session，根据Session产生结果。但如果以REST的状态表述转移模型为指导，我们会自然地得出这样设计：

    每一个页面表示一个状态（存在于客户端），页面包含了到下一个页面的超链接，每当用户选a或选b时分别转移到下一个相应的状态。这样，所有的会话状态其实都是通过url的形式保存在了客户端，服务器端实现了无状态。另外，需要说明的是，虽然上图有7个状态，但并非一定需要在服务器预先生成7个静态页面，它们完全可以是动态页面，这不影响状态转移的概念模型以及服务器无状态的特征。

    有构架设计经验的朋友应该很清楚，与有状态服务设计相比，无状态服务容易实现系统性能的横向扩展。通过增加硬件，部署多个无状态服务，并进行load balance不会受到制约；而有状态服务模式，Session的存储、共享都会带来性能瓶颈，且无法通过增加硬件消除。

    Google搜索就是一个典型的无状态服务。试想一下，当你搜索“周杰伦”以后，Google提示你有数百万的结果，并每10条一页分成若干页，Google会把结果保存进服务器Session吗，然后当你翻页的时候，再从Session中取吗？显然这样庞大的Session，即使是Google也无法承受。

    Google把搜索结果的每一页视为资源（状态），并通过url来表示，同一搜索关键字的不同分页通过start参数来进行区分。当你从第一页点击第二页的链接时，只是从一个状态跳到了下一个状态而已；对于Google而言，其实是一条新的查询（按REST的观点，获取新的资源），而两次查询很可能是由不同的服务器在处理，而用户却感觉Google似乎记住了会话。

    从上面的例子中，我们初步体会到了一点REST风格的味道。但需要说明，REST风格包含了无状态服务器的特征；但反过来，并非具有无状态服务器特征的都是REST。SOA同样可以是无状态的，REST的核心还是资源。