İnternet yavaşladı, kullanıcı sabırsızlandı, butona 3 kez bastı. Ya da mobil uygulama bağlantıyı kesip yeniden aynı isteği gönderdi. Peki sistemin buna hazır mı?
İşte bu gibi durumlarda API'nin ne tepki verdiğini belirleyen önemli bir kavram var: Idempotency (tekrar edilebilirlik).
Bu yazıda sana, teknik terimlere boğmadan, “aynı istek 10 kere gelirse ne olur?” sorusunu net bir şekilde açıklayacağım.
Idempotency, bir işlemi bir kez yapmanla, aynı işlemi 10 kez yapman arasında hiçbir fark olmaması demektir.
Yani API'ye aynı isteği tekrar tekrar gönderdiğinde, sistem aynı sonucu verir ve bozulmaz.
DELETE /products/10
isteği ürünü siler.
Bu isteği tekrar tekrar gönderirsen: ürün zaten silinmiş olur, sistem yine sakin kalır.
POST /orders
isteği her çağrıldığında yeni bir sipariş oluşturur.
10 kez çağırırsan 10 sipariş oluşturur — bu idempotent değildir.
Kısacası: Idempotency, sistemin aynı isteğe birden fazla yanıt vermemesi için bir güvenlik katmanıdır.
Gerçek dünyada ağ sorunları, çift tıklamalar veya mobil uygulama hataları nedeniyle aynı istek birden fazla kez
Eğer sistem bu tekrarları düzgün karşılayamazsa, hatalı veri oluşur:
Idempotency sayesinde sistem, aynı isteğin tekrarlandığını anlar ve ekstra işlem yapmadan durumu korur.
Kullanıcı ödeme yaptı, ama sayfa takıldı. Yeniden “Gönder” dedi.
Eğer işlem idempotent değilse: aynı ürün iki kez satılır, para iki kez çekilir.
Eğer idempotent ise: sistem “bu işlem zaten yapılmış” der ve tekrar etmez.
Kritik işlemlerde (sipariş, ödeme, silme) idempotency bir güvenlik zorunluluğudur.
Her HTTP methodu idempotent değildir. Bazıları tekrarlandığında aynı sonucu verirken, bazıları her seferinde sistemi değiştirir.
Method | Idempotent mi? | Açıklama |
---|---|---|
GET |
✅ Evet | Veri getirir, sonucu değiştirmez. |
DELETE |
✅ Evet | Silme işlemi tekrar edilse de sonuç değişmez. |
PUT |
✅ Evet | Kaynağı baştan yazar. 5 kez yazsan da sonuç aynıdır. |
POST |
❌ Hayır | Her çağrıda yeni kayıt oluşturur, sonucu değiştirir. |
PATCH |
⚠️ Değişken | İçeriğe bağlı olarak değişebilir. Genelde idempotent değildir. |
Sonuç: GET, PUT ve DELETE gibi methodlar tekrarlandığında sistemi bozmaz. Ama POST dikkat ister: her seferinde yeni işlem başlatır.
Idempotency, her API için şart değildir ama bazı işlemler için hayati önemdedir.
Gerçekçi yaklaşım: Sistemin kritik noktalarında tekrarlayan istekleri göz önüne al, idempotency uygulayarak hata riskini azalt.
Özellikle POST
istekleri için "idempotency key" kullanmak, hem kullanıcıyı hem sistemi korur.
Sonuç: Idempotency, küçük bir önlemle büyük hataların önüne geçmektir.
Idempotency-Key desteği eklemek için hem istemciyi hem de sunucuyu küçük adımlarla yapılandırmalısın.
Idempotency-Key
üret. guid
, crypto.randomUUID()
veya başka bir benzersiz string.Idempotency-Key
başlığına ekle.IdempotencyKeys
tablosu oluştur.409 Conflict
döndür. Not: Key’leri veritabanında saklayabilir, Redis gibi hızlı çözümlerle geçici olarak tutabilirsin.
API’niz her POST isteğinde yeni bir Idempotency-Key
üretiyor ve bunlar veritabanında birikiyor. Zamanla bu tablo milyonlarca kayda ulaşabilir.
public DateTime CreatedAt { get; set; }
public void EskiKeyleriTemizle()
{
var eskiKeyler = _db.IdempotencyKeys
.Where(x => x.CreatedAt < DateTime.UtcNow.AddDays(-3))
.ToList();
_db.IdempotencyKeys.RemoveRange(eskiKeyler);
_db.SaveChanges();
}
API Türü | Saklama Süresi |
---|---|
Ödeme / Para işlemi | 24 – 72 saat |
Basit form işlemleri | 1 – 6 saat |
Kritik işlemler | 7 gün (manuel temizlenebilir) |
Not: Temizlik işlemini Hangfire
, Windows Task Scheduler
veya basit bir Timer
ile zamanlayabilirsin.