Http請求方式
其中HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD 方法品追。
HTTP1.1 新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和CONNECT 方法爆惧。
- GET： 請求指定的頁面信息，并返回實(shí)體主體。
GET可以說是最常見的了谈况，它本質(zhì)就是發(fā)送一個請求來取得服務(wù)器上的某一資源。資源通過一組HTTP頭和呈現(xiàn)據(jù)（如HTML文本，或者圖片或者視頻等）返回給客戶端到踏。GET請求中，永遠(yuǎn)不會包含呈現(xiàn)數(shù)據(jù)尚猿。 - HEAD：類似于get請求,只不過返回的響應(yīng)中沒有具體的內(nèi)容窝稿，用于獲取報(bào)頭。
HEAD和GET本質(zhì)是一樣的凿掂，區(qū)別在于HEAD不含有呈現(xiàn)數(shù)據(jù)伴榔，而僅僅是HTTP頭信息。有的人可能覺得這個方法沒什么用缠劝，其實(shí)不是這樣的潮梯。
想象一個業(yè)務(wù)情景：欲判斷某個資源是否存在，我們通常使用GET惨恭，但這里用HEAD則意義更加明確秉馏。 - PUT：從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
本質(zhì)上來講脱羡， PUT和POST極為相似萝究，都是向服務(wù)器發(fā)送數(shù)據(jù)免都，但它們之間有一個重要區(qū)別，PUT通常指定了資源的存放位置帆竹，而POST則沒有绕娘，POST的數(shù)據(jù)存放位置由服務(wù)器自己決定。
舉個例子：如一個用于提交博文的URL栽连，/addBlog险领。如果用PUT，則提交的URL會是像這樣的”/addBlog/abc123”秒紧，其中abc123就是這個博文的地址绢陌。而如果用POST，則這個地址會在提交后由服務(wù)器告知客戶端熔恢。目前大部分博客都是這樣的脐湾。顯然，PUT和POST用途是不一樣的叙淌。具體用哪個還取決于當(dāng)前的業(yè)務(wù)場景秤掌。
DELETE：刪除某一個資源。
基本上這個也很少見鹰霍，不過還是有一些地方比如amazon的S3云服務(wù)里面就用的這個方法來刪除資源闻鉴。POST：向指定資源提交數(shù)據(jù)，進(jìn)行處理請求(例如提交表單或者上傳文件)茂洒。數(shù)據(jù)被包含在請求體中椒拗。POST請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改。
OPTIONS：這個方法很有趣获黔，但極少使用蚀苛。它用于獲取當(dāng)前URL所支持的方法。若請求成功玷氏，則它會在HTTP頭中包含一個名為“Allow”的頭堵未，值是所支持的方法，如“GET, POST”盏触。
CONNECT：HTP/1. 1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器渗蟹。
TRACE： 回顯服務(wù)器收到的請求，主要用于測試或診斷赞辩。
GET和POST的區(qū)別
1雌芽、GET請求，請求的數(shù)據(jù)會附加在URL之后即請求行辨嗽，以?分割URL和傳輸數(shù)據(jù)世落，多個參數(shù)用&連接。URL的編碼格式采用的是ASCII編碼糟需，而不是uniclde屉佳，即是說所有的非ASCII字符都要編碼之后再傳輸谷朝。
而POST請求會把請求的數(shù)據(jù)放置在請求實(shí)體中。數(shù)據(jù)是以流的方式寫過去武花，不會在地址欄上面顯示圆凰。
因此，GET請求的數(shù)據(jù)會暴露在地址欄中体箕，而POST請求則不會专钉。
2、傳輸數(shù)據(jù)的大小
在HTTP規(guī)范中累铅，沒有對URL的長度和傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制驶沼。但是在實(shí)際開發(fā)過程中，對于GET争群，特定的瀏覽器和服務(wù)器對URL的長度有限制。因此大年，在使用GET請求時换薄，傳輸數(shù)據(jù)會受到URL長度的限制。（因?yàn)樗菍懺诘刂窓诘模?br>
而對于POST請求翔试，由于不是URL傳值轻要，理論上是不會受限制的，但實(shí)際上各個服務(wù)器會規(guī)定對POST提交數(shù)據(jù)大小進(jìn)行限制垦缅，Apache冲泥、IIS等服務(wù)器都有各自的配置。
3壁涎、安全性
POST的安全性比GET的高凡恍。
這里的安全是指真正的安全，而不同于上面GET提到的安全方法中的安全怔球，上面提到的安全僅僅是不修改服務(wù)器的數(shù)據(jù)嚼酝。比如，在進(jìn)行登錄操作竟坛，通過GET請求闽巩，用戶名和密碼都會暴露再URL上，因?yàn)榈卿涰撁嬗锌赡鼙粸g覽器緩存以及其他人查看瀏覽器的歷史記錄的原因担汤，此時的用戶名和密碼就很容易被他人拿到了涎跨。除此之外，GET請求提交的數(shù)據(jù)還可能會造成Cross-site request frogery攻擊崭歧。
