- Konu sahibi
- #1
HTTP GET, sunucudan bir kaynağı okumak veya aramak için kullanılır; istek parametreleri çoğunlukla URL içinde taşınır. POST ise veriyi istek gövdesinde sunucuya göndermek, yeni bir işlem başlatmak veya mevcut bir kaynağı işlemek için kullanılır. Bu nedenle ürün arama gibi yalnızca okuma işlemleri GET, kayıt oluşturma veya form gönderme gibi işlemler POST ile yapılmalıdır. POST kullanmak veriyi kendiliğinden şifrelemez; gizlilik için HTTPS gerekir.
GET isteğinde filtre, arama ve sayfalama gibi değerler URL'nin sorgu bölümünde yer alır:
Sunucu bu isteği alır, ilgili ürün listesini üretir ve yanıt gövdesinde sonucu döndürür. Aynı adres daha sonra tarayıcıda yenilenebilir, yer imi yapılabilir veya paylaşılabilir. Arama sonuçlarının URL ile temsil edilmesi bu yöntemi özellikle kullanışlı kılar.
GET ile istemcinin talep ettiği anlam, sunucu durumunu değiştirmek olmamalıdır. Sunucunun erişim günlüğü yazması gibi uygulama içi yan etkiler bu güvenli yöntem tanımına aykırı değildir. Tarayıcı, vekil sunucu veya başka bir ara sistem GET yanıtını önbelleğe alabilir; bu nedenle GET adresine silme, ödeme veya sipariş oluşturma gibi yan etkili işlemler bağlanmamalıdır. URL'ler tarayıcı geçmişinde, sunucu günlüklerinde ve analiz sistemlerinde görülebileceği için parola, oturum belirteci veya özel bilgiler GET parametresi olarak gönderilmemelidir.
POST isteğinde gönderilecek veri genellikle istek gövdesinde bulunur. Örneğin yeni bir destek talebi için uygulama şu alanları gönderebilir:
Sunucu bu veriyi doğrular, yetki kontrolü yapar ve talebi oluşturur veya uygun işlemi yürütür. POST yalnızca kayıt eklemek için kullanılmaz; dosya yükleme, giriş formu, ödeme başlatma ve karmaşık filtrelerin gönderilmesi gibi durumlarda da tercih edilebilir. POST gövdesi URL'de görünmese de ağ üzerinde korunmuş sayılmaz; HTTPS kullanılmadığında veri okunabilir veya değiştirilebilir.
Aşağıdaki ayrım, bir form veya API uç noktası tasarlarken pratik bir başlangıçtır.
POST verisinin URL'de görünmemesi güvenlik için tek başına yeterli değildir. Hassas veriler için HTTPS, sunucu tarafı doğrulama, uygun oturum yönetimi ve gerekiyorsa CSRF koruması birlikte uygulanmalıdır. Ayrıca GET yanıtlarının önbelleğe alınabileceği, POST yanıtlarının ise işlem sonucuna göre tasarlanması gerektiği unutulmamalıdır.
Bir bağlantının arkasına silme işlemi koymak önemli bir hatadır; bağlantılar ve otomatik tarayıcılar GET isteğini tetikleyebilir. Silme, sipariş veya benzeri yan etkili işlemler açık bir kullanıcı eylemi ve uygun bir istek yöntemiyle korunmalıdır. Diğer bir hata, POST'u güvenlik yöntemi sanmaktır. POST yalnızca verinin URL'den ayrılmasını sağlar; taşıma güvenliği HTTPS ile sağlanır. Son olarak, GET'i yalnızca URL kısa olduğu için, POST'u da yalnızca veri gizlenecekmiş gibi seçmek yerine işlemin anlamını ve yan etkisini esas alın.
GET nasıl çalışır?
GET isteğinde filtre, arama ve sayfalama gibi değerler URL'nin sorgu bölümünde yer alır:
/urunler?arama=klavye&sayfa=2Sunucu bu isteği alır, ilgili ürün listesini üretir ve yanıt gövdesinde sonucu döndürür. Aynı adres daha sonra tarayıcıda yenilenebilir, yer imi yapılabilir veya paylaşılabilir. Arama sonuçlarının URL ile temsil edilmesi bu yöntemi özellikle kullanışlı kılar.
GET ile istemcinin talep ettiği anlam, sunucu durumunu değiştirmek olmamalıdır. Sunucunun erişim günlüğü yazması gibi uygulama içi yan etkiler bu güvenli yöntem tanımına aykırı değildir. Tarayıcı, vekil sunucu veya başka bir ara sistem GET yanıtını önbelleğe alabilir; bu nedenle GET adresine silme, ödeme veya sipariş oluşturma gibi yan etkili işlemler bağlanmamalıdır. URL'ler tarayıcı geçmişinde, sunucu günlüklerinde ve analiz sistemlerinde görülebileceği için parola, oturum belirteci veya özel bilgiler GET parametresi olarak gönderilmemelidir.
POST nasıl çalışır?
POST isteğinde gönderilecek veri genellikle istek gövdesinde bulunur. Örneğin yeni bir destek talebi için uygulama şu alanları gönderebilir:
Kod:
konu=Sunucu+erişimi&mesaj=Bağlantı+kontrolü&oncelik=normal
Sunucu bu veriyi doğrular, yetki kontrolü yapar ve talebi oluşturur veya uygun işlemi yürütür. POST yalnızca kayıt eklemek için kullanılmaz; dosya yükleme, giriş formu, ödeme başlatma ve karmaşık filtrelerin gönderilmesi gibi durumlarda da tercih edilebilir. POST gövdesi URL'de görünmese de ağ üzerinde korunmuş sayılmaz; HTTPS kullanılmadığında veri okunabilir veya değiştirilebilir.
Karar vermeyi kolaylaştıran farklar
Aşağıdaki ayrım, bir form veya API uç noktası tasarlarken pratik bir başlangıçtır.
| Konu | GET | POST |
|---|---|---|
| Temel amaç | Kaynak okumak veya aramak | Veri göndermek ve işlem başlatmak |
| Verinin yeri | URL sorgu parametreleri | İstek gövdesi |
| Paylaşılabilirlik | Genellikle yüksektir; adres sonucu temsil eder | İstek gövdesi adreste bulunmaz |
| İstenen durum değişikliği | Olmamalıdır | Olabilir; sunucu işlemi yürütür |
| Tipik örnek | Ürün arama, listeleme, detay görüntüleme | Kayıt oluşturma, giriş, dosya yükleme |
POST verisinin URL'de görünmemesi güvenlik için tek başına yeterli değildir. Hassas veriler için HTTPS, sunucu tarafı doğrulama, uygun oturum yönetimi ve gerekiyorsa CSRF koruması birlikte uygulanmalıdır. Ayrıca GET yanıtlarının önbelleğe alınabileceği, POST yanıtlarının ise işlem sonucuna göre tasarlanması gerektiği unutulmamalıdır.
Bir form veya API için uygulanabilir seçim
- İşlemin yalnızca veri okuyup okumadığını belirleyin. Kullanıcı arama yapıyor veya bir kaynağın ayrıntısını istiyorsa GET seçin.
- İşlem sunucuda kayıt oluşturuyor, değişiklik yapıyor ya da bir iş başlatıyorsa POST kullanın. Güncelleme ve silme için API'nin kaynak tasarımına uygun diğer HTTP yöntemlerini de değerlendirin; her işlemi POST'a çevirmeyin.
- GET kullanıyorsanız yalnızca paylaşılması ve günlüklerde görünmesi sakıncalı olmayan sorgu değerlerini URL'ye koyun. Uzun veya hassas veriyi bu yolla taşımayın.
- POST kullanıyorsanız gövde biçimini açıkça belirleyin; örneğin web formu için form kodlaması, API için JSON kullanın ve uygun
Content-Typedeğerini gönderin. - Sunucuda gelen veriyi tür, uzunluk, biçim ve yetki açısından doğrulayın. Başarılı işlemde hangi kaynağın veya sonucun üretildiğini, hatada ise istemcinin düzeltebileceği alanı belirgin bir yanıtla bildirin.
- Başarılı bir POST sonrasında 303 See Other ile sonuç sayfasına yönlendirme, yenilemede aynı formun yeniden gönderilmesini azaltabilir. Ödeme gibi kritik işlemlerde bu akışı sunucu tarafı mükerrer işlem kontrolünün yerine koymayın.
Sık yapılan hatalar
Bir bağlantının arkasına silme işlemi koymak önemli bir hatadır; bağlantılar ve otomatik tarayıcılar GET isteğini tetikleyebilir. Silme, sipariş veya benzeri yan etkili işlemler açık bir kullanıcı eylemi ve uygun bir istek yöntemiyle korunmalıdır. Diğer bir hata, POST'u güvenlik yöntemi sanmaktır. POST yalnızca verinin URL'den ayrılmasını sağlar; taşıma güvenliği HTTPS ile sağlanır. Son olarak, GET'i yalnızca URL kısa olduğu için, POST'u da yalnızca veri gizlenecekmiş gibi seçmek yerine işlemin anlamını ve yan etkisini esas alın.