REST（表述性状态转移）是最近几年讨论的最为热烈的话题之一，其起源于Roy.T.Fielding博士的论文《软件架构风格和基于网路的软件架构设计》。Roy博士在他的论文里从架构风格角度阐述了网络应用程序中最佳架构风格REST。
首先，REST是一个架构风格而不是一个架构，所谓架构风格就是凌驾于架构之上的一组约束。
其次，REST对立面是RPC，而不是webservices或者SOAP，最近一些年关于REST和RPC的争论一直不断
再次，一般的互联网服务调用存在两种User Agent，一种是普通浏览器，另一种是Client程序，REST主要针对是第二者，系统集成时候各个系统之间的服务调用
REST强调的是尽可能多的用HTTP协议本身的语义来传达信息，这样能减少服务双方关于语义共识的需要
在我看来，REST是标准的互联网技术，在企业内网应用价值大打折扣，因为在互联网中，随时有新的服务供应商产生，你永远也不知道将来可能要调用谁的服务，也永远不知道将来谁会把服务改掉，所以使用传统RPC服务使用者和服务供应者之间的沟通的协调难度非常大。而在企业内网虽然系统也很庞大，但是再庞大的系统也被认为是封闭的，可估算的，你很容易地知道要调用哪些服务。
MartinFowler在最近的一篇文章里描述了逐步实现REST的四个级别：
0级：传统的RPC，基于SOAP的WS，调用的服务名，参数放在HTTP协议的body里面，同时必须以POST方式提交，问题在于你必须清楚的知道所有服务，子服务，及其参数的信息，并且需要知道各种服务的不同点。
1级：利用resource概念，把所有服务都抽取成resource概念，从body中提取到header里，这样做的好处就是如果你知道一个服务地址，你可能无需知道具体服务是什么，依照资源的惯例就访问到服务，比如/books/1。
2级：利用HTTP动词，HTTP定义了4种动词，GET获取服务器资源，POST在服务器上创建新资源，PUT更改服务器上资源，DELETE删除服务器上资源，任何操作都可以看成增删改查，所以利用标准的http verb加上resource（/book/1）就能准确地操作资源，当你不知道服务具体是什么的时候也可以轻易按照惯例访问到服务，然而服务供应商更改服务也需要遵循惯例，不会像RPC那样轻易更改服务接口。
3级：*别，超媒体既应用状态引擎。这个意思是说，对于任何服务都存在很多子服务，你只需要知道第一个服务的入口，便可以依据服务返回结构的自描述性得到下一个服务的入口，这样在服务供应商修改服务的时候，不会影响到客户端的调用。