Apakah perbezaan utama antara kaedah permintaan HTTP GET dan POST?

Tujuan

• GET meminta perwakilan sumber. Mengikut spesifikasi ia adalah baca sahaja: pelanggan tidak menjangkakan sebarang perubahan keadaan pelayan. RFC 9110 menyatakan bahawa menghantar badan dalam permintaan GET mempunyai semantik yang tidak ditentukan, jadi GET tidak sepatutnya membawa badan.
• POST meminta sumber sasaran untuk memproses data yang disertakan dalam badan permintaan mengikut semantik sumber itu sendiri (buat rekod, serahkan borang, muat naik fail, dsb.).

Ke mana perginya data

• GET membawa parameter dalam rentetan pertanyaan URL (selepas ?, diformatkan sebagai key=value&...). Ini boleh dilihat dalam bar alamat dan direkodkan dalam sejarah penyemak imbas dan log pelayan, dan dihadkan oleh had panjang URL yang praktikal.
• POST membawa data dalam badan permintaan; jenis diberikan oleh pengepala Content-Type. Borang HTML biasanya menggunakan application/x-www-form-urlencoded (lalai) atau multipart/form-data (untuk fail). Tiada had saiz tahap protokol tetap, tetapi pelayan dan proksi mengkonfigurasi maksimum mereka sendiri (cth. Nginx client_max_body_size).

Sifat setiap RFC 9110

• Selamat: GET selamat (baca sahaja); POST tidak.
• Idempoten: permintaan adalah idempoten jika menjadikannya N kali mempunyai kesan yang sama pada keadaan pelayan seperti membuatnya sekali. GET adalah idempoten; POST bukan — mengulanginya boleh membuat pendua, seperti dua pesanan yang sama. Idempoten tidak sama dengan selamat (PUT dan DELETE adalah idempoten tetapi tidak selamat), dan ia tidak mengatakan apa-apa tentang badan tindak balas yang sama.
• Boleh cache: GET respons boleh cache secara lalai; Respons POST boleh dicache hanya apabila ia menyertakan maklumat kesegaran eksplisit dan pengepala Content-Location yang sepadan, yang jarang berlaku dalam amalan.

Implikasi praktikal

• Gunakan GET untuk mendapatkan semula dan navigasi; keputusan boleh diulang dengan selamat, penanda halaman dan diambil awal, dan menyegarkan halaman GET adalah tidak berbahaya.
• Gunakan POST untuk tindakan mengubah keadaan dan untuk menghantar muatan sensitif atau besar. Menyegarkan semula atau menavigasi kembali ke halaman POST mencetuskan amaran "sahkan penyerahan semula borang" penyemak imbas.
• Jangan sekali-kali menghantar kata laluan melalui GET — kata laluan itu akan tiba di URL, log dan sejarah. Ini adalah kebersihan, bukan penyulitan: HTTPS menyulitkan kedua-dua URL dan badan dalam transit, tetapi URL masih dilog.

Susulan biasa

• Kaedah selamat adalah GET, HEAD, OPTIONS; kaedah idempoten ialah GET, HEAD, PUT, DELETE; POST juga tidak.
• Kedua-dua kaedah disokong oleh borang HTML (atribut method).
• "Selamat" dalam erti kata RFC bermaksud tiada perubahan keadaan, bukan perlindungan data.
• Idempotensi POST peringkat aplikasi sering dikuatkuasakan menggunakan kunci idempotency.