REST（Representational State Transfer）最早是在2000年由美国加州大学的Roy Fielding在毕业论文 中提出的。如果说Petri网创始人的想法在学术界得到追捧，那么REST这个想法的确在工业界引起了一起狂大的热潮。REST使得人们重新开始思考服务设计的原则和方法。在这片短文里，我将简单讲述一些RESTful风格服务的设计原则。
REST定义了一个架构设计原则，其核心思想是服务的设计以系统资源为中心而不是以服务的功能为中心，包括资源的状态如何表示并如何通过HTTP传输给用不同语言编写的客户端。随着REST的设计理念逐渐被越来越多的人接受，实现了REST的框架相继出现，JCP也制定了JSR 311 (JAX-RS: Java API for RESTful Web Services)规范并做为Java 6的一部分进行了发布。
当我们在设计Restful服务的时，应该遵循一下设计原则：
原则一： 使用HTTP的方法进行资源访问
1) 使用HTTP POST方法去创建 资源
2) 使用HTTP GET方法去读取 资源
3) 使用HTTP PUT 方法去更新 资源
4) 使用HTTP DELETE方法去删除 资源
原则二： 使用无状态/无会话的服务设计
很长时间以来，人们采用有状态的服务设计从而在客户端与服务端的多次交互中维护一定的上下文。表格分页应用就是最常见的一个例子，通常程序员在HTTP Session中保持当前页的变量currentPage，当用户用地址http://www.foo.com/articles?action=nextPage来获取下一页的时候，服务可以根据currentPage获取下一页的数据，即返回第currentPage+1页的数据。
然而，有状态的设计使得程序很难随着工作负载的增加而进行伸缩。比如某个服务实例拥有10000个会话的状态，则通常很难通过增加服务实例来分担其工作负载：工作负载被锁定了！ 反之，如果程序被设计成一个无状态的，则可以自由增加服务实例，并且在这些实例之间平衡负载，从而使得服务具有较好的伸缩性，这在大规模分布式系统中尤其重要！！
原则三： 用目录结构风格的URL设计来表示资源
用清晰的URL路径表示资源可以使客户端更容易理解和操作资源。URL可以被看作是一种自我解释的接口，不需要太多解释就可以让人明白该URL指向的是什么资源以及如何获得相关的资源。
下面是几个例子，供大家参考：
http://www.foo.com/research/articles/{article_title}
http://www.foo.com/research/articles/{year}/{month}/{day}/{article_title}
原则四： 使用XML或JSON来传输数据
服务和请求的消息数据中包含了对于资源的属性的描述，服务应该采取结构良好并且易于阅读的方式来描述资源。资源可能是数据库中的某个记录集合或者是一个具体的记录，可以是文档，甚至可以是数据中心的服务器。XML、JSON都是结构良好的语言，并且适于阅读。我个人比较偏好使用JSON，更加简洁。下面是两个XML和JSON消息的例子，供大家参考。
JSON Example:
{
"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}
}
相应的XML：
<menu id="file" value="File">
<popup>
<menuitem value="New" onclick="CreateNewDoc()" />
<menuitem value="Open" onclick="OpenDoc()" />
<menuitem value="Close" onclick="CloseDoc()" />
</popup>
</menu>
最后，用一小段总结一下REST和XML-RPC的区别，从而加深大家对REST的理解。大家经常会碰到很多用XML表示数据并用HTTP进行传输消息的应用，那么是不是这些应用都是RESTful风格的呢？其实未必。本质区别就在于URL所表示的是资源还是功能，如果是资源则是RESTful风格的，如果是功能则是XML-RPC.