HTTP之为什么存在post,get,put,delete等多种类型请求（RESTful风格介绍）
一、HTTP中定义了以下几种请求方法:
1、GET；2、POST；3、PUT；4、DELETE;
5、HEAD；6、TRACE；7、OPTIONS；
二、各个方法介绍：
1、GET方法：对这个资源的查操作。
2、DELETE方法：对这个资源的删操作。但要注意：客户端无法保证删除操作一定会被执行，因为HTTP规范允许服务器在不通知客
户端的情况下撤销请求。
3、HEAD方法：与GET方法的行为很类似，但服务器在响应中只返回实体的主体部分。这就允许客户端在未获取实际资源的情
况下，对资源的首部进行检查，使用HEAD，我们可以更高效的完成以下工作：
在不获取资源的情况下，了解资源的一些信息，比如资源类型；
通过查看响应中的状态码，可以确定资源是否存在；
通过查看首部，测试资源是否被修改；
4、TRACE方法：会在目的服务器端发起一个“回环”诊断，我们都知道，客户端在发起一个请求时，这个请求可能要穿过防火墙、代理、网关、或者其它的一些应用程序。这中间的每个节点都可能会修改原始的HTTP请求，TRACE方法允许客户端在最终将请求发送服务器时，它变成了什么样子。由于有一个“回环”诊断，在请求最终到达服务器时，服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文的最终模样。这样客户端就可以查看HTTP请求报文在发送的途中，是否被修改过了。
5、OPTIONS方法：用于获取当前URL所支持的方法。若请求成功，则它会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。
二、方发之间的区别：
1、PUT和POST
PUT和POS都有更改指定URI的语义.但PUT被定义为idempotent的方法，POST则不是.idempotent的方法:如果一个方法重复执行
多次，产生的效果是一样的，那就是idempotent的。也就是说：
PUT请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以PUT用来改资源）
Post请求：后一个请求不会把第一个请求覆盖掉。（所以Post用来增资源）
2、get和post
1、GET参数通过URL传递，POST放在Request body中。
2、GET请求会被浏览器主动cache，而POST不会，除非手动设置。
3、GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
4、Get 请求中有非 ASCII 字符，会在请求之前进行转码，POST不用，因为POST在Request body中，通过 MIME，也就可以传输非 ASCII 字符。
5、 一般我们在浏览器输入一个网址访问网站都是GET请求
6、HTTP的底层是TCP/IP。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。但是请求的数据量太大对浏览器和服务器都是很大负担。所以业界有了不成文规定，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。
7、GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
8、在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。但并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
内容整理来源如下：
http://www.cnblogs.com/logsharing/p/8448446.html
http://www.cnblogs.com/shanyou/archive/2011/10/17/2215930.html
http://www.jellythink.com/archives/806
————————————————
版权声明：本文为CSDN博主「田园园野」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_36183935/article/details/80570062
===================================================================================
目录
一、传统常用对数据操作API接口方式
1.请求URI路径命名与请求方式type混乱
2.混乱的URI命名与Type类型导致资源的来源复杂多样
3.状态性（我们一般访问的网页都是有状态）
4. 返回结果重定义
二、RESTful风格例子
1.URI请求命名规则与请求方式
2.返回状态码
三、RESTful风格系统特点
1.CS结构
2.无状态
3.可缓存
4.分层系统
5.统一接口
6.按需代码（扩展性）可选
一、传统常用对数据操作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 （删除一个商品信息）
URI名称 方法 描述
/orgz/members
GET
获取成员列表
/orgz/members/120
GET
获取单个成员
/orgz/members
POST
创建成员
/orgz/members/120
PUT
修改成员
/orgz/members
PUT
批量修改
/orgz/members/120
PATCH
修改成员的部分属性
/orgz/members/120
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）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（比如客户可以在客户端下载脚本生成密码访问服务器。）
————————————————
版权声明：本文为CSDN博主「绣花针」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/mmake1994/article/details/88633636
