GET/POST請求的合理使用

   在咱們求職之初，可能都會被問到Http請求中的GET/POST有什麼區別!當時咱們可能會認爲這還有區別？！可能由於編碼習慣，咱們會在doGet()方法裏調用doPost()方法【或者互相調用】。但咱們真的瞭解它們嗎？

    Tim Berners-Lee在1996年曾經撰文闡述這個問題：GET請求用於從服務器獲取信息，POST請求則用於改變服務器的狀態。

    雖然對普通用戶的正常訪問來講，這2種方法看似沒有多大區別，可是對一些「非正常」訪問來講就有很大影響了！好比常見的蜘蛛爬蟲、網頁加速器這些自動化腳原本說。如今咱們就聯繫網頁加速器進行剖析！

     網頁加速器其實是一段客戶端代碼，它能夠幫助用戶提升瀏覽網頁的速度——奧妙在於，它會預先緩存頁面。也就是說，當用戶瀏覽當前頁面時，加速器會掃描頁面上的連接，並在後臺預先讀取連接背後的頁面，將它們緩存起來。
     如今，請想象你正在瀏覽一個在線商店，頁面上有不少「放入購物車」的連接。當你還在這條栗色 短褲與那件紫色上衣之間猶豫不決時，加速器早己忙碌地訪問了全部這些連接——每一個連接都會往你的購 物車裏放上一件新的貨品。
     這個問題其實一直都存在：搜索引擎和其餘爬蟲程序一直不停地追蹤網頁上的連接。不過通常而言， 會改變服務器狀態的那些連接(譬如「放入購物車」)都不會被暴露出來，只有用戶開始交易以後才能看 到，所以爬蟲也沒法追蹤它們。但網頁加速不一樣，它是在客戶端運行的，因而忽然之間，全部這些連接都 在它面前暴露無遺了。

     在理想的世界裏，任何有反作用的請求都應該以POST(或者是——不多用到的——PUT或者DELETE，而非GET)的形式提交——不該該用連接，而是應該用表單與按鈕來要求服務器執行操做。

    這真的是一個問題麼？和以往同樣，答案是「看狀況」。若是你在應用程序中放了一些危險的連接(譬如「刪除訂單」、「解僱員工」、「發射導彈」之類的)，這些連接確實有可能被無心中訪問到，而後你的應用程序就會忠實地執行這些操做。

     只要遵循一個簡單的原則，就能夠有效地避免出現危險連接。這個原則真的很簡單：永遠不要直接 用<a href="…">這樣的連接來做危險的事情，由於這些連接有可能在用戶絕不知曉的狀況下被程序訪 問到。 下面的技術能夠幫助你在工做中貫徹這一原則：

    （1）使用表單和按鈕（而非超連接）來執行會改變服務器狀態的操做。表單能夠用POST方式提交，這也就是說爬蟲不會致使請求提交，而且當你刷新結果頁面時瀏覽器會發出警告。

    （2）使用確認頁面。若是確實沒法使用表單，就應該讓超連接指向一個確認界面，要求用戶點擊按鈕提交表單完成確認。這樣以來，爬蟲或網頁加速器就沒法形成太大傷害了！

    （3）不要覺得給連接加上一個js確認框就能保護，這樣也沒法阻止爬蟲或別的自動工具追蹤連接。

     （4）不要覺得只有登陸用戶權限控制就能確保安全，雖然爬蟲機關用盡，但客戶端程序（如google的網絡加速器 ）仍然能夠。

   

     這也許有點恐怖，真實狀況也並不是如此糟糕，只有在設計網站時遵循「把可能有風險的請求經過POST提交」這一簡單原則就能夠避免！

摘自：《Web開發敏捷之道-應用Rails進行敏捷Web開發-第三版》，P.377

附：get/post 區別

1. get是從服務器上獲取數據，post是向服務器傳送數據。
2. get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中，值和表單內各個字段一一對應，在URL中能夠看到。post是經過HTTP post機制，將表單內各個字段與其內容放置在HTML HEADER內一塊兒傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對於get方式，服務器端用Request.QueryString獲取變量的值，對於post方式，服務器端用Request.Form獲取提交的數據。
4. get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，通常被默認爲不受限制。但理論上，IIS4中最大量爲80KB，IIS5中爲100KB。
5. get安全性很是低，post安全性較高。可是執行效率卻比Post方法好。 

建議：
一、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數據提交方式；
二、在作數據查詢時，建議用Get方式；而在作數據添加、修改或刪除時，建議用Post方式；