一、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