อะไรคือความแตกต่างที่สำคัญระหว่างวิธีการร้องขอ GET และ POST HTTP?

วัตถุประสงค์

• GET ขอเป็นตัวแทนของทรัพยากร ตามข้อกำหนด เป็นแบบอ่านอย่างเดียว: ไคลเอนต์ไม่คาดหวังการเปลี่ยนแปลงสถานะเซิร์ฟเวอร์ใดๆ RFC 9110 ตั้งข้อสังเกตว่าการส่งเนื้อหาในคำขอ GET นั้นมีความหมายที่ไม่ได้กำหนดไว้ ดังนั้น GET จึงไม่ควรมีเนื้อหา
• POST ขอให้ทรัพยากรเป้าหมายประมวลผลข้อมูลที่อยู่ในเนื้อหาคำขอตามความหมายของทรัพยากรนั้น (สร้างบันทึก ส่งแบบฟอร์ม อัปโหลดไฟล์ ฯลฯ)

ข้อมูลไปไหน

• GET มีพารามิเตอร์ในสตริงการสืบค้น URL (หลัง ? ซึ่งจัดรูปแบบเป็น key=value&...) สิ่งเหล่านี้สามารถมองเห็นได้ในแถบที่อยู่และบันทึกไว้ในประวัติเบราว์เซอร์และบันทึกเซิร์ฟเวอร์ และถูกจำกัดด้วยความยาว URL ที่จำกัดในทางปฏิบัติ
• POST นำข้อมูลไปไว้ในเนื้อหาคำขอ ประเภทที่กำหนดโดยส่วนหัว Content-Type โดยทั่วไปรูปแบบ HTML จะใช้ application/x-www-form-urlencoded (ค่าเริ่มต้น) หรือ multipart/form-data (สำหรับไฟล์) ไม่มีการจำกัดขนาดระดับโปรโตคอลคงที่ แต่เซิร์ฟเวอร์และพรอกซีกำหนดค่าสูงสุดของตัวเอง (เช่น Nginx client_max_body_size)

คุณสมบัติต่อ RFC 9110

• ปลอดภัย: GET ปลอดภัย (อ่านอย่างเดียว) โพสต์ไม่ได้
• Idempotent: คำขอจะเป็น idempotent หากสร้าง N ครั้งจะมีผลเช่นเดียวกันกับสถานะเซิร์ฟเวอร์เช่นเดียวกับการสร้างครั้งเดียว GET คือ idempotent; ไม่ใช่ POST — การทำซ้ำอาจสร้างรายการซ้ำ เช่น คำสั่งซื้อที่เหมือนกันสองรายการ Idempotent นั้นไม่เหมือนกับ safe (PUT และ DELETE นั้นเป็น idempotent แต่ไม่ปลอดภัย) และไม่ได้บอกว่าเนื้อหาการตอบสนองจะเหมือนกันเลย
• แคชได้: การตอบกลับ GET สามารถแคชได้ตามค่าเริ่มต้น การตอบกลับ POST สามารถแคชได้ก็ต่อเมื่อมีข้อมูลความใหม่ที่ชัดเจนและส่วนหัว Content-Location ที่ตรงกัน ซึ่งพบได้ยากในทางปฏิบัติ

ผลกระทบในทางปฏิบัติ

• ใช้ GET สำหรับการดึงข้อมูลและการนำทาง ผลลัพธ์สามารถทำซ้ำ บุ๊กมาร์ก และดึงข้อมูลล่วงหน้าได้อย่างปลอดภัย และการรีเฟรชหน้า GET นั้นไม่เป็นอันตราย
• ใช้ POST สำหรับการดำเนินการที่เปลี่ยนแปลงสถานะและสำหรับการส่งเพย์โหลดที่ละเอียดอ่อนหรือขนาดใหญ่ การรีเฟรชหรือการนำทางกลับไปยังหน้า POST จะทำให้เกิดคำเตือน "ยืนยันการส่งแบบฟอร์มอีกครั้ง" ของเบราว์เซอร์
• อย่าส่งรหัสผ่านผ่าน GET เพราะรหัสผ่านเหล่านั้นจะไปอยู่ใน URL บันทึก และประวัติ นี่คือสุขอนามัย ไม่ใช่การเข้ารหัส: HTTPS เข้ารหัสทั้ง URL และเนื้อหาระหว่างการส่ง แต่ URL ยังคงถูกบันทึกไว้

การติดตามผลทั่วไป

• วิธีการที่ปลอดภัยคือ GET, HEAD, OPTIONS; วิธีการ idempotent คือ GET, HEAD, PUT, DELETE; POST ก็เช่นกัน
• ทั้งสองวิธีรองรับรูปแบบ HTML (แอตทริบิวต์ method)
• "ปลอดภัย" ในแง่ RFC หมายถึงไม่มีการเปลี่ยนแปลงสถานะ ไม่ใช่การปกป้องข้อมูล
• บ่อยครั้งมีการบังคับใช้ POST idempotency ระดับแอปพลิเคชันโดยใช้คีย์ idempotency