Mehmet

WFN Üye
Konular
1,851
Mesajlar
1,852
Çözüm
0
Ticaret Puanı
0
Üyelik
1 Ay 6 Gün
Konum
YurtDışı
Web Sitesi
Var
Alanı
Google Adsense
1/1
Konu sahibi
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 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=2

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 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.

KonuGETPOST
Temel amaçKaynak okumak veya aramakVeri göndermek ve işlem başlatmak
Verinin yeriURL sorgu parametreleriİstek gövdesi
PaylaşılabilirlikGenellikle yüksektir; adres sonucu temsil ederİstek gövdesi adreste bulunmaz
İstenen durum değişikliğiOlmamalıdırOlabilir; sunucu işlemi yürütür
Tipik örnekÜrün arama, listeleme, detay görüntülemeKayı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​


  1. İş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.
  2. İş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.
  3. 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.
  4. 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-Type değerini gönderin.
  5. 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.
  6. 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.

Sık sorulan sorular​

GET isteğinde gövde kullanılabilir mi?​

Bazı istemciler gövde gönderebilse de GET içeriğinin genel olarak tanımlanmış bir anlamı yoktur; sunucular ve ara sistemler bunu reddedebilir. Tarayıcı Fetch API de GET için gövde kabul etmez. Taşınabilir bir arama uç noktası için paylaşılabilir ve hassas olmayan parametreleri sorgu bölümünde kullanın.

POST yanıtı hiçbir zaman önbelleğe alınmaz mı?​

Bu kadar kesin değildir. HTTP, uygun açık tazelik bilgisi ve gerekli koşullarda POST yanıtının önbelleğe alınmasına izin verir; yaygın önbelleklerin desteği sınırlı olabilir. Özel kullanıcı verisinin saklanmasını yöntem adına bakarak varsaymayın. Yanıtın Cache-Control politikasını ve kullanılan ara katmanın davranışını ayrıca belirleyin.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Konuyu görüntüleyenler

Bu konuyu şu anda görüntüleyen üye bulunmuyor.