通俗的解释Restful
假设我们要去一家西餐厅吃饭，向前台服务员说，“一个芝士蛋糕，一杯拿铁，两条吸管，谢谢啦”。
Level 0 - 面向前台
“向前台点一杯拿铁”，用JSON来表示如下
{
"addOrder": {
"orderName": "latte"
}
}
“我们通过这样一段代码，告诉前台，我们新增了一笔订单，订单是一杯拿铁”，然后前台给了我们下面这段回复
{
"orderId": "123456"
}
“如上即代表是订单的编号”，之后，等前台喊123456的客户取餐即可
接下来，假设我们有一张会员卡，我们想查询会员卡的余额，这时候就要向前台发另一个询问，如下
{
"queryBalance": {
"cardId": "886333"
}
}
“查询卡号为886333”会员卡的余额，之后前台返回如下
{
"balance": "0"
}
没钱了，那就只好取消这笔订单了
{
"deleteOrder": {
"orderId": "123456"
}
}
Level 1 - 面向资源
何为面向资源呢，假设我们还是要下单，如下
/orders
{
"addOrder": {
"orderName": "latte"
}
}
订单是一种资源，/orders可以理解为是咖啡厅专门管理订单的人，可以处理相关订单的各种操作。
接着继续返回订单号
{
"orderId": "123456"
}
接下来继续查询余额
/cards
{
"queryBalance": {
"cardId": "886333"
}
}
家下来继续取消订单
/orders
{
"deleteOrder": {
"orderId": "123456"
}
}
Level 2 - 打上标签
接下来继续优化，负责订单的人，需要处理关于订单的各种操作，每次都要判断里面是何种操作很麻烦，所以，在新增的资源里都要加上资源请求的类型，例如新增资源使用POST标注，查询用GET，删除用DELETE，“还有修改类的，修改分为两种，第一种，如果这个修改，无论发送多少次，最后一次修改后的资源，总是和第一次修改后的一样，比如将拿铁改为猫屎，那么用‘PUT’表示；第二种，如果这个修改，每次修改都会让这个资源和前一次的不一样，比如是加一杯咖啡，那么这种请求用‘PATCH’或者‘POST’表示”
POST /orders
{
"orderName": "latte"
}
接下来查询余额
GET /cards
{
"cardId": "886333"
}
上面的请求可以优化为
GET /cards/886333
取消订单同样道理
DELETE /orders/123456
Level 3 - 完美服务
店家返回信息里，他们不仅返回用户的订单编号，还返回可以对订单进行的操作，如下
{
"orderId": "123456",
"link": {
"rel": "cancel",
"url": "/order/123456"
}
}
这样就不用再次请求返回信息了
总结
REST是英文representational state transfer(表象性状态转变)或者表述性状态转移;Rest是web服务的一种架构风格;使HTTP,URI,XML,JSON,HTML等广泛流行的标准和协议;轻量级,跨平台,跨语言的架构设计;它是一种设计风格,不是一种标准,是一种思想。
- Level 0和Level 1的最大区别是Level 1有了RESTFUL的第一个特征面向资源，这对构建可伸缩、分布式的架构是至关重要的，如果把Level0的数据格式换成Xml，那么其实就是SOAP，SOAP（对于应用程序开发来说，使程序之间进行因特网通信是很重要的。目前的应用程序通过使用远程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信，但是 HTTP 不是为此设计的。RPC 会产生兼容性以及安全问题；防火墙和代理服务器通常会阻止此类流量。通过 HTTP 在应用程序间通信是更好的方法，因为 HTTP 得到了所有的因特网浏览器及服务器的支持。SOAP 就是被创造出来完成这个任务的。SOAP 提供了一种标准的方法，使得运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相进行通信。）的特点是关注行为和处理，和面向资源的RESTful有很大的不同。
Level 0和Level 1都不好，因为他们只是把HTTP当做一个传输的通道，没有把HTTP当做一个传输协议。 - Level 2，真正的将HTTP当做一个传输协议，它使用了HTTP动词，GET/POST/DELETE/PATCH等，这些都是HTTP的规范，规范的作用自然是重大的，用户看到一个POST请求，就知道它不是幂等的，使用时要小心，看到PUT，就知道他是幂等的，调用多几次都不会造成问题，当然，这些的前提都是API的设计者和开发者也遵循这一套规范，确保自己提供的PUT接口是幂等的。
- Level 3可以理解为每个资源都有它的状态，，在不同的状态下，可以对他进行的操作不一样，理解了Level 3 再来理解RESTFUL的意思，“表述性状态转移”就很好理解了。
Level3的Restful API，给使用者带来了很大的便利，使用者只需要知道如何获取资源的入口，之后的每个URI都可以通过请求获得，无法获得就说明无法执行那个请求。
现在绝大多数的RESTful接口都做到了Level2的层次，做到Level3的比较少。当然，这个模型并不是一种规范，只是用来理解Restful的工具。所以，做到了Level2，也就是面向资源和使用Http动词，就已经很Restful了。Restful本身也不是一种规范，我比较倾向于用“风格"来形容它。如果你想深入了解Level3，可以阅读《Rest in Practice》第五章。
