當使用者首次登入一個網站時，會出現這個網站的登入頁，使用者輸入賬號和密碼後，單擊“提交”按鈕，如果認證通過則登入成功。這個過程中網頁和後台伺服器進行了多次互動，這中間到底發生了哪些事情呢？
使用者在瀏覽器的位址列中輸入一個網站的登入頁地址，目的是從伺服器上拉取登入頁的 HTML 檔案。在這個過程中，瀏覽器向後台發起了 HTTP GET 的請求（這個請求也可能是從其他頁面中的連結發起的），登入頁比較常見的 URL 形式是 http://xxx/login。
從 GET 請求這個名字中，讀者大致可以猜到，這種型別的請求是從伺服器拉取資源而不改變伺服器的資源。
瀏覽器收到登入頁的 HTML 檔案並解析後，使用者看到的是使用者名稱和密碼的輸入介面，輸入後單擊“提交”按鈕，這時瀏覽器又向伺服器發了一個請求，不過發起這次請求時，使用者並沒有在位址列輸入什麼，位址列的內容也沒有立刻發生改變（一般情況下，開啟連結後，位址列的內容會立刻發生改變）。
這次向伺服器發起的是 HTTP POST 請求，從 POST 的名字中讀者可以大致猜到，這種型別的請求會帶一些發起者的資料並讓伺服器發生一些改變。
通常認為 GET 就是拉取伺服器的資料，POST 就是向伺服器提交資料，但實際上兩者並沒有這種明確的界限，前端開發人員有時很任性，怎麼操作方便怎麼來，所以使用者經常會在登入頁輸入賬號和密碼，登入後看到位址列立刻從 http://xxx/login 變成了 http://xxx/login?usemame=xxxx&password=xxxx。
當然，敏感資訊是經過加密的，上述例子中，頁面直接將登入資訊補到 URL 中 並行起了一次 HTTP GET 的請求。
有時，因為有的操作用 HTTP GET 不太方便，所以前端開發人員更依賴 HTTP POST 的操作。以上傳一張圖片為例，將圖片資料編碼後新增到 URL 後面的引數中傳給伺服器是可行的，只是有的瀏覽器（比如 IE）對 URL 的長度有限制，所以前端開發會覺得一會用 POST 傳資料，一會用 GET 傳資料太麻煩，傳資料乾脆全用 POST 好了。
HTTP POST 請求將需要攜帶的資訊放在 HTTP 請求的資料欄位中，在 URL 中是看不到的，所以有時使用者在頁面裡操作，頁面一直在變化，但是位址列的 URL 卻一直沒變過（這只是一種原因，很多 Web 技術都可以實現這種效果）。
後台開發人員則會做相容處理，一般都會同時支援 HTTP GET 和 HTTP POST 來取或傳資料，做到只關心資料內容而不關心傳送形式。