Sự khác biệt chính giữa các phương thức yêu cầu HTTP GET và POST là gì?

Mục đích

• GET yêu cầu đại diện cho một tài nguyên. Theo đặc điểm kỹ thuật, nó ở chế độ chỉ đọc: máy khách không mong đợi bất kỳ thay đổi trạng thái máy chủ nào. RFC 9110 lưu ý rằng việc gửi nội dung trong yêu cầu GET có ngữ nghĩa không xác định, vì vậy GET không được mang nội dung.
• POST yêu cầu tài nguyên đích xử lý dữ liệu kèm theo trong nội dung yêu cầu theo ngữ nghĩa riêng của tài nguyên đó (tạo bản ghi, gửi biểu mẫu, tải tệp lên, v.v.).

Dữ liệu đi đâu

• GET mang các tham số trong chuỗi truy vấn URL (sau ?, được định dạng là key=value&...). Chúng hiển thị trên thanh địa chỉ và được ghi lại trong lịch sử trình duyệt cũng như nhật ký máy chủ, đồng thời được giới hạn bởi giới hạn độ dài URL thực tế.
• POST mang dữ liệu trong phần thân yêu cầu; loại được đưa ra bởi tiêu đề Content-Type. Các biểu mẫu HTML thường sử dụng application/x-www-form-urlencoded (mặc định) hoặc multipart/form-data (dành cho tệp). Không có giới hạn kích thước cấp giao thức cố định, nhưng các máy chủ và proxy định cấu hình mức tối đa của riêng chúng (ví dụ: Nginx client_max_body_size).

Thuộc tính theo RFC 9110

• An toàn: GET an toàn (chỉ đọc); POST thì không.
• Idempotent: một yêu cầu sẽ không có hiệu lực nếu việc thực hiện nó N lần có tác động tương tự đến trạng thái máy chủ như việc thực hiện một lần. GET là bình thường; POST thì không - việc lặp lại nó có thể tạo ra các bản sao, chẳng hạn như hai đơn hàng giống hệt nhau. Idempotent không giống như an toàn (PUT và DELETE là idempotent nhưng không an toàn) và nó không nói gì về việc nội dung phản hồi giống hệt nhau.
• Có thể lưu vào bộ nhớ đệm: Các phản hồi GET được lưu vào bộ nhớ đệm theo mặc định; Phản hồi POST chỉ có thể lưu vào bộ nhớ đệm khi chúng bao gồm thông tin mới rõ ràng và tiêu đề Content-Location phù hợp, điều này rất hiếm trong thực tế.

Ý nghĩa thực tiễn

• Sử dụng GET để truy xuất và điều hướng; kết quả có thể được lặp lại, đánh dấu trang và tìm nạp trước một cách an toàn và việc làm mới trang GET là vô hại.
• Sử dụng POST cho các hành động thay đổi trạng thái và để gửi tải trọng lớn hoặc nhạy cảm. Việc làm mới hoặc điều hướng quay lại trang POST sẽ kích hoạt cảnh báo "xác nhận gửi lại biểu mẫu" của trình duyệt.
• Không bao giờ gửi mật khẩu qua GET — chúng sẽ xuất hiện trong URL, nhật ký và lịch sử. Đây là vấn đề vệ sinh, không phải mã hóa: HTTPS mã hóa cả URL và nội dung khi truyền nhưng URL vẫn được ghi lại.

Theo dõi phổ biến

• Các phương thức an toàn là GET, HEAD, OPTIONS; các phương thức bình thường là GET, HEAD, PUT, DELETE; POST cũng không.
• Cả hai phương pháp đều được hỗ trợ bởi biểu mẫu HTML (thuộc tính method).
• “An toàn” theo nghĩa RFC có nghĩa là không thay đổi trạng thái, không bảo vệ dữ liệu.
• Tính tạm thời POST ở cấp độ ứng dụng thường được thực thi bằng cách sử dụng các khóa bình thường.