項目 | GET | POST |
---|---|---|
資料位置 | 放在網址(Query String) | 放在 Request Body |
安全性 | 參數容易被看到(帳密會「裸奔」) | 資料不在網址中 |
用途 | 讀取資料(搜尋、查詢) | 傳送資料(登入、上傳、表單) |
快取 | 可被快取 | 不容易快取 |
為什麼登入表單幾乎都用 POST?
HTTP Header 是請求中最容易被忽略但其實超重要的部分。它們負責「夾帶瀏覽器與使用者資訊」讓伺服器知道怎麼處理這個請求
Header 名稱 | 說明 |
---|---|
Host | 告訴伺服器「你想去哪個網站」 → 一個伺服器可能有多個網站,靠這個分流 |
User-Agent | 告訴伺服器「你是用什麼設備 / 瀏覽器來的」 |
Referer | 告訴伺服器「你是從哪一個頁面連過來的」 |
Cookie | 附帶之前伺服器設定的 Cookie(例如登入身分) |
Content-Type | 告訴伺服器 Body 的資料格式 |
Content-Length | 告訴伺服器 Body 的長度(位元組) |
User-Agent
欄位裡常看到:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...
這跟 Mozilla 軟體社群有關。早期網頁標準支援差,很多網站只對「Mozilla 系瀏覽器」開放進階功能,後來各家瀏覽器(例如 Chrome、Safari)為了相容,也都在 UA 裡放上「Mozilla/5.0」,成為歷史遺留。
Request Body 就是 POST、PUT、PATCH 請求中「要送給伺服器的資料」,例如登入資訊、表單內容、JSON。
常見 Header 搭配:
Content-Type: application/json
Content-Length: 123
範例 :
{
"username": "ken",
"password": "1234"
}
瀏覽器發出 Request 後,伺服器會回一個 Response,包含狀態碼、標頭、資料。
範例:
HTTP/2 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1024
<html>...</html>
HTTP/2 200 OK
HTTP/2
→ 協定版本200
→ 狀態碼OK
→ 狀態描述類別 | 範圍 | 意義 |
---|---|---|
1xx | 100–199 | 資訊(少見) |
2xx | 200–299 | 請求成功 |
3xx | 300–399 | 重新導向 |
4xx | 400–499 | 使用者/請求有錯 |
5xx | 500–599 | 伺服器出錯 |
狀態碼 | 名稱 | 說明 |
---|---|---|
200 | OK | 一切正常 |
301 | Moved Permanently | 永久搬家(轉址) |
302 | Found | 臨時轉址 |
304 | Not Modified | 沒變,瀏覽器用快取 |
400 | Bad Request | 請求格式錯 |
401 | Unauthorized | 未登入 |
403 | Forbidden | 沒權限 |
404 | Not Found | 找不到 |
405 | Method Not Allowed | 方法不被允許 |
500 | Internal Server Error | 伺服器爆炸 |
502 | Bad Gateway | 中繼站壞了 |
503 | Service Unavailable | 忙碌或維修 |
504 | Gateway Timeout | 超時 |
418 | I’m a teapot | 茶壺搶救大作戰(愚人節彩蛋) |
HTTP 418 "I'm a teapot" 是 1998 年 IETF 愚人節提案 RFC 2324 的一部分。
它的意思是:「如果你對茶壺發送泡咖啡的請求,它會拒絕並回傳 418:我只是茶壺,泡咖啡不關我事」
如今它變成工程師圈的幽默彩蛋