原文作者：互联网人 原文地址：http://w3er.com/blog/2009/04/a-brief-analysis-about-restful-web-services/
这是我以前写的一篇文章，最近我在博客上不是推荐了OpenResty吗？发现很多人还不理解Rest的概念，所以放到这里，希望对大家有益。
首先说下什么是REST，这个四个字母是Representational State Transfer的简写，它是一套设计原则：表示性状态转移。接着我们再看下Web背后的暗藏的设计理念和传统的Web服务（RPC式的）的差别：
- Web是基于资源的，但很多传统的Web服务并不会暴露资源；
- Web是基于URI与链接的，但很多传统的Web服务一般也只暴露一个URI和零个链接；
- Web是基于HTTP的，但很多传统的Web服务几乎很少使用HTTP的特性；
- Web是可以面向对象的，但很多传统的Web服务几乎都面向过程。
从而传统的Web服务，就会出现一些不好地方：
- 不具有寻址性；
- 不具有可缓存性；
- 没有连通性；
- 不是冥等的，也不是安全的；
- 不符合统一接口（通常一个不同服务的操作千差万别）；
- 不透明（即你熟悉了一个服务不代表另一个也熟悉）。
大家可能对上面的一些关键词不太理解，现在我就做一下说明，这里还包括一些下面可能用到的词语：
- 寻址性：如果一个Web服务将其数据集里有价值的部分作为资源发布出来，那么该应用就是可以寻址的，每个资源必须对应唯一的一个URI，建议同一资源的不同表示也对应一个URI；
- 资源状态：即关于资源的信息，一定要保存到服务器端，且只能以表示的实现的形式发给客户端；
- 应用状态：即关于客户端在应用中所处的状态信息，比如起始页码，一定要保存到客户端，可以作为请求的一部分发给服务端，甚至成为资源状态的一部分；
- 冥等性：不管你对某资源做多少次同样的操作，结果总是一样的；
- 安全性：始终不会改变服务器的状态；
- 连通性：资源应该是可以容易的相互连接起来的，服务器通过超媒体（即超文本表示里的链接和表单）可以引导资源从一个状态进入下一个状态，Roy Field也在论文里说：“将超媒体作为应用状态的引擎”；
- 统一接口：客户端和资源之间的所有交互都应该是通过为数不多的几个基本的HTTP方法进行的。
若一个REST式的服务从不保存任何应用状态，那么就称它为无状态的。在一个无状态的应用里，服务是按照当前的资源状态来独立处理各个客户端请求的，是冥等的。而无状态的好处是：
- 提升应用的规模十分简单；
- 具有更高的可靠性，就是说多次重发一对一个资源的请求是冥等的。
若一个服务的连通性做得好，那么客户端就不需要去理解这个服务的潜在规则来构造uri。在REST式服务中，对于HTTP几个基本方法的约定：
- GET：用于获取关于资源的信息；
- HEAD：只获取报头（一些元信息），不获取表示；
- PUT：请求设定资源状态（创建或者修改），若客户端向一个URI发送PUT请求时未提供表示，则表明此URI处已经存在一个资源了；
- DELETE：请求用于删除资源；
- POST：请求为已有的资源创建一个从属资源或者；
- OPTIONS：请求用于查看一个资源支持统一接口里的哪些方法。
重载POST方法虽然可以不违背REST的设计原则（符合最低要求），但它是违反面向资源的架构原则的，而统一接口的好处并不在于它所暴露的具体方法，而在于统一性，从而提高与其他Web服务的兼容性。一个服务应该是自描述的，而不依赖于辅助的文字描述来告诉程序员怎么编码，而且，依赖于URI构造规则的客户端是比较脆弱的，一但改变了规则，所有客户端都要重写。在REST式的Web服务的资源设计时，要注意资源的合理设计，资源可以分为三类：
- 预定义的一次性资源：比如服务的主页；
- 大量（或者无数个）对应于个数据项的资源；
- 大量（或者无数个）对应于一个可能的算法输出结果的资源。
记住：拿不准时，就可以把它作为资源。在设计资源的URI时，路径变量被用于分隔一个层次结构或者有向图的元素，如果同一层次的多项数据有次序关系就用逗号（ , ），如果同一层次的多项数据没有先后关系就用分号（ ; ）。表示应当是人类可读的，但同时也应当是面向计算机的。也应当是有用的，应该暴露的是有价值的数据而不是无用的数据。记住，你的服务可能要考虑版本化的问题，如果拿不准就在资源的最前面加上路径变量来表示版本吧。