Skip to main content
“Idempotent” bir istek, aynı girdi ile birden fazla kez gönderildiğinde yan etki yaratmayacak istektir. GET, PUT, DELETE doğası gereği idempotenttir — aynı URL’e tekrar istek atmak kaynak durumunu değiştirmez (veya kasten değiştirir ama tekrarlanabilir). POST ise genellikle yeni bir kaynak oluşturur; aynı POST’u iki kez gönderirseniz iki kayıt oluşur.
Flextell API şu anda Idempotency-Key header’ı gibi yerleşik bir idempotency mekanizmasını desteklemez. Bu sayfa, bu eksiğe rağmen güvenli yazma yapmanız için önerilen örüntüleri özetler. İleride resmi bir Idempotency-Key desteği eklenirse Changelog’da duyururuz.

Hangi istekler dikkat ister?

Aşağıdaki yazma uçları yan etki yaratır ve yanlışlıkla iki kez gönderilmesi hoş olmayan sonuçlar doğurabilir:
  • POST /v1/appointments — çift randevu
  • POST /v1/sales — çift satış kaydı
  • POST /v1/sales/{id}/payments — çift tahsilat
  • POST /v1/stocks/entry — çift stok girişi
  • POST /v1/stocks/adjustment — çift düzeltme
  • POST /v1/stocks/transfer — çift transfer
  • POST /v1/conversations/{id}/messages — aynı mesajın iki kere gönderilmesi

Örüntü 1 — İstemcide kilit (en basit)

Bir butonu “gönderim sırasında” devre dışı bırakın:
Bu, tek bir sekmedeki çift tıklamayı kapsar ama sunucu tarafı tekrar sorununu (istemci 500 aldı ama istek aslında işlendi) çözmez.

Örüntü 2 — Doğal anahtar ile kontrol

Veri modelinizin “doğal bir eşsiz anahtarı” varsa, isteği atmadan önce kaynağın zaten var olup olmadığını kontrol edin. Örnek: Randevu oluştururken (customer_id, starts_at, doctor_id) doğal olarak eşsizdir. Önce bir GET ile aynı kombinasyona sahip aktif randevu var mı kontrol edin; yoksa oluşturun.

Örüntü 3 — İstemci tarafı idempotency anahtarı

Kendi tarafınızda bir UUID üretip isteklerle eşleştirin. Aynı UUID için birden fazla gönderim olursa sunucuya atmadan önce yerel tablonuzdan önceki sonucu döndürün.
Bu tek bir istemci oturumundaki duplikasyonu çözer ama farklı cihaz/oturumları korumaz.

Örüntü 4 — Sunucu yanıtını kontrol etme

Çağrı zaman aşımına uğradı veya ağ hatası verdi; istek gerçekten işlendi mi bilmiyorsunuz. Tekrar göndermeden önce kaynağı sorgulayın:

Öneriler

  • Para ve stok etkileyen uçlarda mutlaka bir deduplikasyon örüntüsü kullanın.
  • Mesaj gönderimi gibi yüksek hacimli uçlarda kullanıcıya “gönderiliyor…” göstergesi bırakın; ağ hatasında satırı “tekrar dene” butonuyla kullanıcıya bırakın.
  • Otomatik retry yalnızca 429, 5xx ve ağ hatalarında uygulanmalı; 4xx hatalarında isteği tekrarlamak sorunu çözmez.