从"SOAP"到"REST"
最近有很多同仁问我，我们为什么要用REST？REST比SOAP好在哪？对于这个问题我想了不下十种答案。但转念一想，如何以一种最直接，类似于武侠小说中"一剑封喉"般的方式，"稳准狠"的解答他们的问题。就不至于就此展开一场"辩论赛"或是"科普贴"。好在问我这个问题的同仁大都不是程序猿界的"小鲜肉"，大家对于时下软件研发的基本理念还是有共同认知的，基于此，我对这个问题的标准答案就是："REST更OO"。
如果您还有兴趣深入了解REST和SOAP的区别，我觉得还是自行Google吧。
这篇文章想给大家介绍的重点更偏重于：我们如何从"SOAP"转向"REST"，以及什么样的"RESTful API"才是真正的REST。
虽不赘述SOAP和REST的概念，但还是简单介绍一下何为SOAP，何为REST：
SOAP(Simple Object Access Protocol)：简单对象访问协议
REST(Rerepresentational State Transfer)：表示性状态转移
你在网上能搜到的异同点大致分为主要三个方面：
- SOAP是一种协议，而REST是一种规范
- SOAP支持多种传输协议，而REST目前仅支持HTTP/HTTPS
-
SOAP仅支持XML，而REST支持XML、Json甚至HTML
其实SOAP和REST严格来说不是两个对等的概念，我们姑且理解成两种服务设计思想及其具体的实现架构。
如果说SOAP和REST不够具象，那我来找两位代言人，自行感受一下我们所谓的"SOAP风格"和"REST风格"。
Web Service或是WCF大家想必不陌生，而Web Service和WCF就是利用SOAP协议进行的服务实现（当然他们也支持REST，但很鸡肋，不足以代言）。我们要对外提供服务离不开类似的技术。那我们是如何设计这样的服务接口的呢。说起来真是轻车熟路：我们先定义对象，而后我们设计接口。更有甚者，我们直接定义服务接口。所以一说到Web Service或是WCF我们就会想到接口，我们一看到接口，我们就非常的舒服。那我们为什么舒服，因为这很后台。进程间的接口调用方式总是会给程序员们以莫名的亲切感。
熟悉Web API风格的朋友可能就能想到REST。可Web API的服务应该怎么设计？如果我们还用上面说到设计Web Service/WCF的"SOAP风格"进行服务的设计，那REST比SOAP还有什么优势？仅仅是更轻量级的优势？
我们来举个例子：一只喵儿饿了，他要获取食物，食物分别有鱼和熊掌。所以我们要提供一个服务是食物的获取。基于这个简单的小例子，我们来看看从"SOAP"到"REST"的转型之路。
第一阶段：
我们提供一个为喵儿提供食物的REST服务。接到任务我们开始进行业务分析，最后确定2个方法：吃鱼和吃熊掌，对！就是这样一个简单粗暴的方法，我们想让喵儿调用这些方法，调用EatingFish可以获得鱼，调用EatingBearpaw可以获得熊掌。
我们的思路是：定义对象 --> 定义方法 改写成RESTful风格
很快RESTful API 被定义好了：Get http://service-root/EatingFish和Get http://service-root/EatingBearpaw
喵儿只要用GET请求这些URI就能得到食物。
然而这一版设计很快宣告失败。并不是我们对服务的功能定义出了问题，而是问题出在这个服务"很不RESTful"，原因是：没有站在资源的角度考虑RESTful API的定义，而是延续了"接口"定义的"SOAP风格"。这样从"接口"入手，然后将"接口"以REST的URI形式暴露出来的API仍然是很"SOAP"的，这样定义出的RESTful API，一般是Level 0或Level 1的。
那我们就来介绍一下REST的4个境界，我也称之为REST的"成熟度模型"。
Level 0：没有明确的资源概念，只有一个URL，只是用单个HTTP方法
Level 1：有明确的资源概念，存在很多URL，只是用单个HTTP方法
Level 2：有明确的资源概念，存在很多URL，使用HTTP作为资源的统一接口
Level 3：在满足2级标准的基础上，使用超媒体作为应用状态的引擎
我们再来回过头看看我们的表达Get http://service-root/EatingFish，无疑是Level 0。
即便是我们生硬的在"EatingFish"前将"Food"表达出来也不过是Level1的表达：Get http://service-root/Food/EatingFish
分别参照一下Level 0和Level 1的定义，我们发现Level0的表达没有"资源"的概念，仍然是提供了一个"行为"的"接口"，这种做法像极了"SOAP"。我们再来看看Level 1的表达，虽然已经明确出了"Food"这个资源，Food资源下也可以定义多个针对Food的方法，但仍然定义的是诸如"EatingFish"和"EatingBearPaw"这样的一个个行为来作为资源的方法。
第二阶段：
我们重新思考，要站在"资源"的角度考虑这个服务，而资源的CRUD又可以通过HTTP的POST、GET、PUT和DELETE请求表达。也就是说我们只要把"资源"表述清楚，利用REST的理念CRUD我们就不必考虑了。基于这样的考虑，我们赶快调整思路：定义资源 --表述资源
资源定义：
我们定义了三个资源"Food"作为食物的集合，而"Food"下，有"Fish"和"BearPaw"，对于资源的表述我们采取了Collection+Json的超媒体格式。
资源表述：
{
"collection": {
"version": "1.0",
"href": "http://service-root/Food",
"links": [ ],
"items": [
{
"href": "/Fish",
"data": [
{
"name": "Name",
"value": "鱼"
},
{
"name": "Code",
"value": "Fish"
}
],
"links": [ ]
},
{
"href": "/ BearPaw ",
"data": [
{
"name": "Name",
"value": "熊掌"
},
{
"name": "Code",
"value": " BearPaw "
}
],
"links": [ ]
}
],
"queries":[ ],
"template":{
"data": [
{
"name": "Name",
"value": ""
},
{
"name": "Code",
"value": ""
}
]
},
"error": {
"code": "",
"Message": ""
}
}
}
根据资源的定义，通过Collection+Json这种超媒体类型进行资源的表述。使用HTTP协议语义规定的请求类型作为资源的统一接口，不需要再像Level 0 和Level 1中那样单独定义或描述接口。
这时喵儿如果想要吃鱼，只需要GET http://service-root/Food/Fish他就能获得鱼。而如果我们想要从食物中把熊掌删除掉，也只需要 DELETE http://service-root/Food/BearPaw。如果我们想帮喵增加一种食物-肉，只需要POST http://service-root/Food/Meat，同时利用资源表述中的模板template，将肉的信息传回去，肉这种食物就被添加进了食物中。
这时我们发现我们再去思考服务的设计已经不是站在"要提供什么样的方法"这种基于过程、基于行为的角度去思考。而是基于"资源"的面向对象的设计方法。
做到这个程度，感觉已经非常的RESTful了，但回到REST的本意看看，就体会出了问题的所在。回观REST的定义：REST(Rerepresentational State Transfer)表示性状态转移，多读几遍我们就渐渐的感觉到了一个词："转移"。
而再对照"成熟度模型"我们发现这时候的API已经是Level 2的。Level 2到Level 3，如何表示"转移"成了下一个阶段进阶的关键。
为了更好的展现出第三个阶段的特点，我们现在扩充一下这个小例子，在喵儿获取过食物之后，他还想来点甜点，甜点有蛋糕和冰激凌。（真是只贪得无厌的喵儿）
第三阶段：
继续调整思路：定义资源 --定义资源的链接关系 --> 资源表述
第一步和第三步与第二阶段没有什么差别，而关键在于第二步，REST的本意希望能够通过资源的表述，描述出每个资源与其他资源的链接关系。
回到我们的例子，我们定义资源，这时候会有两棵树，"食物"和"甜点"：
而接下来，我们希望喵儿在获得到食物之后，能够知道接下来有甜点吃。这时我们引入了资源的状态图：
资源的状态图表述的是从当下的资源能够链接到哪个资源。我们可以看到当获取到Fish之后，喵儿就能看到有Desserts，当他访问Desserts时，就能看到为他准备好的Cake和Ice Cream了。
那这种链接如何表述呢？
我们观察到不管是REST的哪一种超媒体格式，都为我们准备了Link字段：
{
"collection": {
"version": "1.0",
"href": "http://service-root/Food ",
"links": [ ],
"items": [
{
"href":"/Fish",
"data": [
{
"name":"Name",
"value":"鱼"
},
{
"name":"Code",
"value":"Fish"
}
],
"links": [
{
"rel":"Desserts",
"href":" http://service-root/Desserts",
"prompt": "甜点"
}
]
},
{
"href":"/ BearPaw ",
"data": [
{
"name":"Name",
"value":"熊掌"
},
{
"name":"Code",
"value":" BearPaw "
}
],
"links":[
{
"rel":"Desserts",
"href":" http://service-root/Desserts",
"prompt": "甜点"
}
]
}
],
"queries": [ ],
"error": {
"code": "",
"Message": ""
}
}
}
在Level 2 的基础上，利用Collection+Json中对Links的表达，表述了资源间转移的关系。如有必要同时利用Queries表达了对资源集合的过滤。至此我们完成了从"SOAP"到"REST"的转变。
一些注意：
1、 定义资源不是在定义逻辑模型，更不是E-R；
2、 一个服务中描述的资源不一定是同一根的，"转移"也可以发生在两棵树之间。
3、 一旦出现了不用Level0 和Level 1就表达不了的情况，基本上就是资源的定义出了问题
4、 REST并不是"银弹"，它解决不了你资源（对象）设计本身的问题。