GET ve POST HTTP istek yöntemleri arasındaki temel farklar nelerdir?

Amaç

• GET bir kaynağın temsilini ister. Spesifikasyon gereği salt okunurdur: istemci herhangi bir sunucu durumunun değişmesini beklemez. RFC 9110, bir GET isteğinde bir gövde göndermenin tanımsız anlambilime sahip olduğunu, dolayısıyla GET'in bir gövde taşımaması gerektiğini belirtir.
• POST hedef kaynaktan istek gövdesinde yer alan verileri kaynağın kendi semantiğine göre işlemesini ister (kayıt oluşturma, form gönderme, dosya yükleme vb.).

Veriler nereye gidiyor

• GET, URL sorgu dizesindeki parametreleri taşır (?'den sonra, key=value&... olarak biçimlendirilmiştir). Bunlar adres çubuğunda görünür, tarayıcı geçmişine ve sunucu günlüklerine kaydedilir ve pratik bir URL uzunluğu sınırıyla sınırlıdır.
• POST istek gövdesindeki verileri taşır; tür Content-Type başlığı tarafından verilir. HTML formları genellikle application/x-www-form-urlencoded (varsayılan) veya multipart/form-data (dosyalar için) kullanır. Protokol düzeyinde sabit bir boyut sınırı yoktur, ancak sunucular ve proxy'ler kendi maksimumlarını yapılandırır (örn. Nginx client_max_body_size).

RFC 9110'a göre özellikler

• Güvenli: GET güvenlidir (salt okunur); POST değil.
• Idempotent: Bir isteğin N kez yapılması, sunucu durumu üzerinde bir kez yapılmasıyla aynı etkiye sahipse bu istek önemsizdir. GET önemsizdir; POST öyle değil; tekrarlanması, iki özdeş sipariş gibi kopyalar oluşturabilir. Idempotent güvenli ile aynı şey değildir (PUT ve DELETE idempotenttir ancak güvenli değildir) ve yanıt gövdesinin aynı olduğu konusunda hiçbir şey söylemez.
• Önbelleğe alınabilir: GET yanıtları varsayılan olarak önbelleğe alınabilir; POST yanıtları yalnızca açık tazelik bilgileri ve eşleşen bir Content-Location başlığı içerdiklerinde önbelleğe alınabilir; bu da pratikte nadirdir.

Pratik çıkarımlar

• Alma ve gezinme için GET'i kullanın; sonuçlar güvenli bir şekilde tekrarlanabilir, yer imlerine eklenebilir ve önceden getirilebilir; ayrıca bir GET sayfasını yenilemek zararsızdır.
• Durum değiştiren eylemler ve hassas veya büyük yüklerin gönderilmesi için POST'u kullanın. Bir POST sayfasını yenilemek veya bu sayfaya geri dönmek, tarayıcının "formun yeniden gönderilmesini onayla" uyarısını tetikler.
• Şifreleri asla GET aracılığıyla göndermeyin; bunlar URL'ye, günlüklere ve geçmişe düşecektir. Bu, şifreleme değil hijyendir: HTTPS, aktarım sırasında hem URL'yi hem de gövdeyi şifreler, ancak URL hâlâ günlüğe kaydedilir.

Yaygın takipler

• Güvenli yöntemler GET, HEAD, OPTIONS'tır; eşpotent yöntemler GET, HEAD, PUT, DELETE'dir; POST ikisi de değil.
• Her iki yöntem de HTML formları (method özelliği) tarafından desteklenir.
• RFC anlamında "Güvenli", veri koruması değil, durum değişikliği olmadığı anlamına gelir.
• Uygulama düzeyinde POST idempotency genellikle idempotency anahtarları kullanılarak uygulanır.