Http協議-get、post、put、delete

      http協議、一種網路中，檔案傳送遵循的協議。一種無狀態的協議、http協議伺服器端不跟瀏覽器端建立長久的通訊串連，即服務端無法識別請求端的到底是誰。建立http通訊之後，服務端將檔案內容傳送給瀏覽器端接收就完成一次請求。當然一個頁面，往往由多個http請求構成、圖片，CSS等資源的請求~可能是一個頁面進行多個http請求之後得到的結果。

    http的無狀態，理解成：不論是哪個瀏覽求向百度發送請求，都是得到同樣的結果。百度伺服器不能確定前後兩次向百度發起請求的是不是同一個用戶端。（當然可以通過cookies、ip分析跟蹤到具體的瀏覽器以及使用者行為）

    在我的機器上請求百度https://www.baidu.com 如圖所示，當請求www.baidu.com這個網址之後，解析到百度服務下對應的資源，同理瀏覽器端所呈現的各種背景圖片、樣式，都會發起http請求得到對應的檔案資源。包括圖片、css樣式檔案資訊跟請求的html檔案，整體構成使用者的瀏覽器端的看到的狀態。

  Http協議，發起請求成功，首先是通過DNS網域名稱解析器，將www.baidu.com這個網域名稱，解析到正確的ip地址的伺服器上，一般情況沒有指定後面具體的資源，瀏覽器會將自動定位到根目錄"/"下即將www.baidu.com拼湊成www.baidu.com/ ,www.baidu.com只是DNS可以解析到ip的網域名稱，"/"是指定資源的位置，一般根目錄下會預設為index檔案（當然這個隨意伺服器配置變更）。其實在瀏覽器直接輸入對應ip地址，進行請求是一樣的。因為伺服器最後請求的實質，就是通過ip進行定位。

  Http協議的狀態代碼，常見的應該是404錯誤，直接拋出頁面不存在的錯誤。當時實際在瀏覽器工作當中，200跟304的響應碼應該是最多的。只是大多數人沒有去看底層http請求響應流程。200應該是瀏覽器發送請求，伺服器接收到了請求，建立串連成功的響應碼。所以當200狀態代碼時候，就是可以正常把伺服器檔案內容傳送到瀏覽器端。304就是在頁面重新整理時候，直接從緩衝裡面拿資料。避免頻繁大量的請求增加伺服器響應的壓力,同時減少使用者等待重新載入CSS、js。圖片的時間~

（意外發現一個彩蛋~~~百度console有招聘資訊~~~~哈哈~~~）

同時發現我登陸狀態請求www.baidu.com跟直接請求ip地址是不一樣的協議，記住密碼登陸下情況下是https協議，走的是443連接埠。而直接ip地址走的是預設的80連接埠。

   記住密碼，會請求登陸頁面，會走post請求~

       這裡就會出現http協議，請求方式get跟post的區別，get請求的時候，一般都是url資源後面“。”跟著對應的參數，多個參數以‘&’符進行串連~所以如果以get方式請求，請求內容一般都是可以直接在url地址欄直接捕捉看到的。但是get請求，會把請求的參數內容封裝在http請求body中~貌似這樣會安全一點，其實用wireshark或者fidder抓包工具，就能很容易捕捉到http請求，body體中傳送的內容。

    就以前為了面試：get跟post 的區別，都會常說兩點，第一，get請求方式，不安全。post安全。第二，get請求參數內容有限制大小，post請求沒有限制。

  這是一種似是而非的答案，其實http協議定義跟這完全沒有關係。第一，get請求不安全，post請求同樣也不安全。原因基於抓包一看，就得到內容。第二，http協議從來就沒有限制過get請求內容的大小，而是瀏覽求對url地址的長度的限制，不同瀏覽器對url請求的參數內容大小會有限制。

   這根http協議定義就有點關聯啦，put/delete/get/pos依次可以對應資料庫的增、刪、改、查。所以get請求一般是查資料的，而且內容是無論請求多少，都是一樣不會發生改變的。當然，get也可以帶參數，這裡狹義的認為，只要不會影響資料結構的請求方式，都是等冪請求。get請求也是http協議定義中的標準使用。

     post、put、delete自然就是不等冪請求，一般會改變資料結構。對應會發生資料結構的改變。這裡如果用過Laravel架構，其中的resource路由的定義，就會這個get、post、delete、put請求方式有深刻的理解。

   同樣的url地址，同樣的參數形式，會因為請求方式的get、post、put、delete的不同，會分別發生不同的行為。得到不同的結果。

    php是一種弱語言，所以當時我選擇php入門的原因。就是因為php使用便捷，沒有其他語言那麼嚴格。其中get、post請求應該是php中用得最多的地方，phper都知道，可以通過$_GET/$_POST分別獲得get、post方式提交的資料。但是經常為了方便，我們會用到$_REQUEST這個全域變數來擷取前台不論是post還是get方式提交過來的值。但是這樣就會產生一個問題，沒有嚴格區分到底是get還是post請求方式提交的資料。容易產生問題，舉一個簡單的例子：如果在頁面刪除一條資料，沒有嚴格區分提交方式，"xxx.delete.php。id=44"類似於這種請求，可以現象這種請求在一個頁面預設都是get請求方式，Google瀏覽器有一個加速器，就是會提前把get請求方式的東西，比如CSS跟js等提前給載入進來，以加快運行效率。如果頁面存在這種delete請求，也會不知不覺中被刪除了資料。這樣就容易導致很嚴重的bug~~當然這隻是一個簡單的便於實際理解的例子，實際情況遠遠沒有這麼簡單容易。不過由此可以引出，明確分清楚，get跟post請求方式，以及put、delete請求方式，在項目中還是很有必要的。

   在瞭解http協議的基礎上，多看看http要求標頭，body體，http應答頭~看這個都就會自然注意到重要訊息明文傳送的危險性。然後在此基礎上加深對get、post、delete、put請求方式的理解，特別推崇Laravel架構的路由resource的路由風格~嚴格遵循了RESTful風格的。