何为REST？特征是什么？

REST有四大特征：

可寻址性：

可寻址性是说每一个资源都应该有一个唯一的URI标识，这样它才能被外界访问。

无状态性：

无状态性具体一点来说是指服务器不应该保存“应用状态”。

类似把资源保存到数据库里的操作保存的是“资源状态”，资源状态保存在服务端很正常，应该仔细区分“资源状态”和“应用状态”，比如说你使用Google搜索rest，然后把结果翻到了第2页，这时的状态就是应用状态，此状态不应该保存在服务端，也就是说，服务端不应该关心你是在第1页还是第2页。相应的，此状态应该由客户端自己保存，当客户端向服务器发送请求的时候，应该把应用状态附加在请求上。

还以上面的Google搜索为例，当翻到第2页的时候，其URI如下：

http://www.google.com/search?hl=en&pwst=1&q=rest&start=10

这里的start=10就是应用状态。

如果在服务端保存应用状态，那么当我们通过增加服务器的方式来提升性能时，由于用户的多次请求可能会分配到不同的服务器上，那么我们就必须让多台服务器共享应用状态，如此一来，性能必然大打折扣。对应的，当客户端自己保存应用状态的话，就意味着用户的每次请求都是自包含的，包括了所有需要的信息，如此一来，我们就可以简单的通过增加服务器来提升性能，这一切都是透明的。

统一接口：

统一接口是说对所有的资源进行的操作都采用一致的方式。

那么我们来思考一下对SOAP而言，为什么要有一个WSDL描述文件呢？其原因就是因为SOAP不是统一接口的。在张三的SOAP接口里，添加动作对应的API是add，而在李四的SOAP里，添加动作对应的API则可能是create，这是因为存在这种不确定性，所以在SOAP里需要有一个WSDL描述文件。

REST强调统一接口，大家都知道使用GET，POST，PUT，DELETE去操作资源进行浏览，添加，修改，删除，完全不需要描述文件。

需要说明的是REST并没有具体规定统一接口到底应该是什么，打个比方来说，如果你所有的资源都用GET方法去实现删除操作，用DELETE方法去实现浏览操作，那也并不违反REST的统一接口标准，因为对你而已，这个接口就是统一的，但与此同时这个REST也就没有普遍意义了，只属于你一个人了，其结果就是对你来说可以算是REST，对别人来说就是一个怪物了，所以在基本问题上最好不要标新立异。

连通性：

连通性是说资源之间不应是孤立的，而是彼此联系的。

网站大多有很好的连通性。比如说前面提到的Google搜索，我们可以通过<form>进行关键字查询：

如：http://www.google.com/search?hl=en&q=rest&

至于为什么是q=rest而不是p=rest，这些并不用浏览者去关心，因为当我们进行关键字查询时，资源间通过<form>实现了连通性，浏览器知道如何去处理这些标签，从而对客户端隐藏了这些实现的细节，并引导客户端完成状态的迁移。

不过很多WebService并没有实现连通性，在它们的实现里，只是简单的使用XML或者JSON去展现数据，各个资源间没有任何联系，无法自然的依靠资源的表象去完成状态的迁移，如此一来，客户端往往是按照预先的某种约定（比如文档）去设置资源间的关系。

比如说常见实现里：

一篇文章的URI是：/articles/123
对应评论的URI是：/articles/123/comments

看上去层次关系很漂亮，但如果评论的URI结构并不是在文章的表象里得到的，而仅仅是按约定设计的，那么这样的设计就是错误的，或者说不是REST的，因为这些约定本身属于业务逻辑的范畴，存在不稳定的因素，按约定去做就等同于把原本属于服务端的逻辑泄漏到了客户端，就像用身份证号码做数据库主键一样不是什么好事情，很容易出问题，导致客户端和服务端的强耦合，一旦服务端的实现方式有变化，必然引起客户端牵一发动全身的影响。所以说，你必须牢记，客户端的状态迁移是在资源表象的指引下进行的，而不是按照预先的某种约定进行的，只有这样才能保证服务端和客户端是弱耦合。

当然，你也可以牵强的把没有连通性的WebService称为REST，但这就好像过去我们判断POJO是充血还是贫血一样，没有连通性的所谓REST无疑是贫血的REST，那感觉就好像我们打开一个网站，却发现里面一个超链接也没有，给人的印象只有无趣与乏味。

本文来自优快云博客，转载请标明出处：http://blog.youkuaiyun.com/yb030832/archive/2010/08/03/5782743.aspx