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，那感觉就好像我们打开一个网站，却发现里面一个超链接也没有，给人的印象只有无趣与乏味。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yb030832/archive/2010/08/03/5782743.aspx