- Konu sahibi
- #1
HTTP POST nedir?
HTTP POST, bir istemcinin sunucuya veri göndermek ve sunucuda bu veriyle bir işlem başlatmak için kullandığı HTTP yöntemidir. Örneğin kayıt formunu gönderme, yeni kullanıcı oluşturma, giriş yapma veya sipariş başlatma işlemleri genellikle POST isteğiyle yapılır. Gönderilen veriler çoğunlukla isteğin gövdesinde (
body) bulunur; bu nedenle veriler URL'nin sorgu bölümüne yazılmak zorunda değildir.POST isteği nasıl çalışır?
Tarayıcı, mobil uygulama veya başka bir istemci sunucuya bir istek gönderir. İstekte hedef yol, HTTP yöntemi, başlıklar ve veri gövdesi bulunabilir. Sunucu isteği doğrular, gerekli işlemi yapar ve bir HTTP durum koduyla yanıt verir.
Örneğin bir uygulamada yeni kullanıcı oluşturmak için istemci şu bilgileri gönderebilir:
Kod:
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
{"name":"Ayşe","email":"[email protected]"}Burada
POST işlemin türünü, /api/users hedefi, Content-Type başlığı ise gövdedeki verinin JSON olduğunu belirtir. Sunucu başarılı olursa yeni kaydın kimliğini ve oluşturulan kaydı içeren bir yanıt döndürebilir. İstemci, yanıtın durum kodunu ve içeriğini kontrol ederek işlemin başarılı olup olmadığını anlamalıdır.POST için gövde ve tekrar gönderim kararı
GET çoğunlukla mevcut bir kaynağı okumak için kullanılır ve filtreler URL'nin sorgu bölümünde taşınabilir. POST ise sunucuya veri gönderme veya sunucuda yeni bir işlem başlatma amacı taşır. POST gövdesi adres çubuğunda görünmediği için veriyi otomatik olarak gizli veya şifreli yapmaz; hassas bilgiler için HTTPS ve sunucu tarafında uygun doğrulama gerekir.
| Konu | POST için karar | Örnek |
|---|---|---|
| Gövde türü | API sözleşmesine uyar | JSON, URL kodlu form veya multipart |
| Tekrar gönderim | Kendiliğinden idempotent değildir | Aynı sipariş iki kez oluşmamalı |
| Başarı yanıtı | İşlem sonucuna göre okunur | 201 yeni kayıt, 202 kabul edildi, 204 içerik yok |
POST kullanmak tek başına güvenlik sağlamaz. Gönderilen veriyi sunucu tarafında doğrulamak, yetki kontrolü yapmak ve uygulamanın gerektirdiği durumlarda CSRF koruması uygulamak gerekir. Ayrıca içerik türü ile gönderilen veri biçimi birbiriyle uyumlu olmalıdır. JSON gönderiyorsanız
Content-Type: application/json belirtin; klasik form gönderiminde ise sunucunun beklediği form kodlamasını kullanın.Basit bir POST isteğini uygulama
Aşağıdaki kurgu örnek tarayıcı JavaScript'i ile JSON gönderir. Sunucu 204 dışında başarılı yanıtta geçerli JSON döndürüyor olmalıdır; farklı sözleşmede gövde okuma yöntemini uyarlayın. Kod burada gerçek kullanıcı oluşturmaz.
/api/users adresinin JSON kabul eden bir sunucu uç noktası olduğu varsayılmıştır:
Kod:
fetch('/api/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
name: 'Ayşe',
email: '[email protected]'
})
})
.then(async response => {
if (!response.ok) {
throw new Error('HTTP hatası: ' + response.status);
}
if (response.status === 204) return null;
return response.json();
})
.then(data => console.log('Sunucu yanıtı:', data))
.catch(error => console.error(error));Uygularken şu sırayı izleyin:
- Sunucuda hangi alanların zorunlu olduğunu ve kabul edilen veri biçimini belirleyin.
- İstemcide
method: 'POST'kullanın ve gövdeyi sunucunun beklediği biçimde hazırlayın. - JSON gönderiyorsanız
Content-Typebaşlığını ekleyin ve nesneyiJSON.stringifyile metne dönüştürün. - Yanıtta
response.okveya durum kodunu kontrol edin; hata gövdesini kullanıcıya uygun bir mesajla işleyin. - Başarılı yanıttaki kimlik veya kayıt bilgisini kullanarak arayüzü güncelleyin ya da gerekiyorsa oluşturulan kayda yönlendirin.
Başarılı sonuç, yalnızca sunucudan yanıt alınması değil, beklenen durum kodunun ve yanıt biçiminin alınmasıdır.
400 benzeri bir yanıt veri doğrulama sorunu, 401 veya 403 yetkilendirme sorunu, 404 yanlış uç nokta, 409 ise çakışan kayıt gibi bir duruma işaret edebilir. Sunucu hatası alındığında istemciyi art arda otomatik göndermek yerine hata gövdesini ve sunucu günlüklerini inceleyin.Sık yapılan hatalar
- JSON gönderip
Content-Typebelirtmemek veya sunucunun JSON ayrıştırıcısını etkinleştirmemek. - İstemci doğrulamasına güvenip sunucuda alan, tür, uzunluk ve yetki kontrolü yapmamak.
- Başarısız HTTP durum kodlarını yalnızca ağ hatası sanıp yanıt gövdesini incelememek.
- POST isteğini kullanıcı yenilediğinde aynı kaydın tekrar oluşabileceğini hesaba katmamak. Kritik işlemlerde sunucu tarafında tekrar gönderim kontrolü veya uygun bir idempotency yaklaşımı tasarlanmalıdır.
Sık sorulan sorular
POST verileri URL'de hiç görünmez mi?
İstek gövdesindeki veriler URL'de görünmez; ancak tarayıcı geliştirici araçlarında, istemci günlüklerinde veya sunucu kayıtlarında görülebilir. HTTPS olmadan ağ üzerinde korunmuş sayılmaz.
POST ile dosya gönderilebilir mi?
Evet. Dosya ve ek alanlar için genellikle
multipart/form-data kullanılır. Sunucu uç noktasının bu içerik türünü desteklemesi ve dosya boyutu ile türü için uygun sınırlar uygulaması gerekir.POST isteği neden 200 yerine başka bir başarı kodu döndürebilir?
Başarı kodu işlemin niteliğine göre değişebilir. 201 yeni kaynağın oluşturulmasını, 202 işlemin kabul edildiğini ancak henüz tamamlanmadığını, 204 ise gövdesiz başarıyı ifade edebilir. Her 2xx sonucunda JSON okumak veya kayıt tamamlandı demek doğru değildir; durum kodunu API sözleşmesiyle birlikte yorumlayın.
