restful诞生的原因：统一接口管理。一套科学的api接口
restful风格接口和传统接口对比：
以员工列表为例子
传统接口：
传统接口设计思考点：
1、请求路径--见名知意：employee/list大概就是访问员工列表的意思
2、请求方式--一般都会忽略：这里也没有指明什么方式请求
3、请求参数--由需求决定
4、请求响应--由需求决定
传统方式的例子：
wwww.langfeiyes.cn/employee/li… ：传统查询全部员工操作
wwww.langfeiyes.cn/employee/ge… ：传统查询员工id=1的信息的操作
wwww.langfeiyes.cn/employee/sa… ：传统保存员工name=xx的信息的操作
restful风格接口：
restful风格接口设计思考点：
1、请求路径--由当前接口操作的资源决定，资源的复述作为路径，比如这里的/employees
再举几个粒子：
api/example/com/v1/zoos：动物园资源
api/example/com/v1/animals：动物资源
这里介绍一个api文档借鉴restful风格：docs.jiguang.cn/jmessage/server/rest_api_im/
2、请求方式--restful风格在http请求方法上做了约定
GET（select）：从服务器取出资源（一项或多项）
POST（create）：在服务器新建一个资源
PUT（update）：在服务器更新资源（）
PATCH（update）：在服务器更新资源
PUT和PATCH的区别是：前者是更新这个对象的所有属性，后者是更新部分属性
DELETE（delete）：从服务器删除资源
上面图片的意思是我要对这个员工进行一个查的操作
restful风格的例子：
http:www/langfeiyes.cn/employees
新增：post
更新：put
删除：delete
查询：get
获取某个部门的所有员工：
GET/employee/getByDeptid --以前的比较随意
GET/departments/{id}/employees -- restful风格
所以也能看出来：传统的路径见名知意=restful路径+请求方式的结合
3、请求参数--由需求决定
4、请求响应--看约定情况，公司该返回什么就返回什么
知识扩展：
资源的表现形式：
accept和content-type的区别：
