目录
一、传统常用对数据操作API接口方式
1.请求URI路径命名与请求方式type混乱
一千个读者就有一千个哈姆雷特，大多数程序员在URI命名时都采取见明知意的方式，使用get或者post解决所有数据的CRUD，如以下方式
http://localhost:8080/mallWeb/getAllProducts ---get查
http://localhost:8080/mallWeb/getSomeProductsById?id=10086 ---get查
http://localhost:8080/mallWeb/saveUserInfo ---post增
http://localhost:8080/mallWeb/updateUserInfoById?id=10086 ---post改
http://localhost:8080/mallWeb/deleteUserInfoById?id=10086 ---post删
每个人都有自己命名的一套规则与请求方式，导致http协议显得混乱，甚至完全忽略了其他请求方式如put、delete等，如果不是因为get请求uri长度限制（一般为2kb），或许很多人通篇get请求，再无其它
2.混乱的URI命名与Type类型导致资源的来源复杂多样
混乱的URI命名导致一个独立的URI地址，无法对应一个独一无二的资源。一个资源，对应了多样v来源；你有没有想过这样一个环境，一个独立的URI地址，对应一个独一无二的资源（RESTful风格）；比如：我是一名理发师，需要为顾客理发；定义如下URI：
/hairStyle/{customer_id}，一个顾客就对应一套理发流程；如/hairStyle/mark，表示我现在需要为mark做一整套理发流程。现在再想想我们之前常用的命名方式
wash/hairStyle/mark，为mark顾客洗头
cut/hairStyle/mark，为mark顾客剪头
dry/hairStyle/mark，为mark顾客吹头
如果我们可以用/hairStyle/mark表示一整套流程，(已经定义了各种type)
如果你要为顾客洗头，追加type=wash；
如果你要为顾客剪头，追加type=cut；
如果你要为顾客剪头，追加type=dry；
这就是RESTful风格之一了，怎么样是不是很清爽呢！Http请求协议中有8中类型！！！想想你用了几种呢？
3.状态性（我们一般访问的网页都是有状态）
有状态：后面每一个状态都依赖于前面的状态，如果前面的无法访问，后面的也不会请求成功，如：
有状态：
员工登录OA系统----进入个人信息中心----进入薪资查询----输入密码----查询工资
如果其中的某个环节操作不成功，都无法查询工资成功
无状态（RESTful风格）：
如果输入一个url即可得到指定员工的工资，则这种情况是无状态的，因为获取工资不依赖于其他资源或状态
http://oa.wasion.com/salary/mark，直接可以获取到mark的工资，这种就是无状态的
4. 返回结果重定义
我想很多人应该封装过如下实体吧，服务器返回错误信息都会封装在Http协议状态码中，我们依然还会错误信息封装在返回值中，返回的状态码一律都是200，返回了true或者false，前端拿到返回值后还要去解析到底是true还是false
public class Json implements java.io.Serializable {
private boolean success = false; //返回是否成功
private String msg = "";//返回消息
private Object obj = null;//返回数据
//get与set...
}二、RESTful风格例子
1.URI请求命名规则与请求方式
GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，Delete用来删除资源
URI的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP动词来体现，所以RESTful风格中 通过 URI 暴露资源时，会强调不要在 URI 中出现动词
原始风格
http://localhost:8080/mallWeb/getAllproducts ---Get （获取所有商品信息）
http://localhost:8080/mallWeb/getProductById?id=pro_id ---Get （获取某个商品信息）
http://localhost:8080/mallWeb/SaveOneProduct ---Post （添加一个商品信息）
http://localhost:8080/mallWeb/UpdateSomeproductsById?id=pro_id ---Post（修改一个商品信息）
http://localhost:8080/mallWeb/DeleteSomeproductsById?id=pro_id ---Post（删除一个商品信息）
RESTful风格
http://localhost:8080/mallWeb/rest/api/products ---Get （获取所有商品信息）
http://localhost:8080/mallWeb/rest/api/products/:pro_id ---Get （获取某个商品信息）
http://localhost:8080/mallWeb/rest/api/products ---Post （添加一个商品信息）
http://localhost:8080/mallWeb/rest/api/products/:pro_id ---Put（修改一个商品信息）
http://localhost:8080/mallWeb/rest/api/products/:pro_id ---Delete （删除一个商品信息）
2.返回状态码
返回值加入返回状态码（code），虽然Http请求本身已经有了完备的状态码，再定义一套状态码直观上感受却是不对劲。但是实际开发中，确实发现自定义业务状态码的必要性，如一次成功的Http status 200的请求，可能由于用户未登录、登录过期而有不同的返回结果和处理方式，所以还是保留了状态码（code）
public class Json implements java.io.Serializable {
private boolean success = false; //返回是否成功
private String msg = "";//返回消息
private Object obj = null;//返回数据
private String code = ""; //返回状态码
//get与set...
}状态码的定义也最好有一套规范，如按照用户相关、授权相关、各种业务，做简单的分类
// Code 业务自定义状态码定义示例
// 授权相关
1001: 无权限访问
1002: access_token过期
1003: unique_token无效
...
// 用户相关
2001: 未登录
2002: 用户信息错误
2003: 用户不存在
// 业务1
3001: 业务1XXX
3002: 业务1XXX
三、RESTful风格系统特点
1.CS结构
客户端-服务器结构
2.无状态
服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用
3.可缓存
服务器必须让客户知道请求是否可以被缓存
4.分层系统
服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持
5.统一接口
客户和服务器之间通信的方法必须是统一化的（GET，POST，PUT，DELETE，etc）
6.按需代码（扩展性）可选
服务器可以提供一些代码或者脚本（Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（比如客户可以在客户端下载脚本生成密码访问服务器。）