Hata Durumunda Geri Alma ve Çakışma Çözümü

İyimser bir eklemeyi (öğeyi kaldırma) veya silmeyi (öğeyi geri yükleme) geri almak kolaydır. Bir güncellemeyi geri almak ise daha karmaşıktır: tam olarak önceki değeri geri yüklemeniz gerekir. Bir öğe iyimser olarak birden çok kez güncellendiyse yalnızca ilk sunucu durumunu değil, her bir önceki değeri ayrı ayrı izlemeniz gerekir.

Şu senaryoyu düşünün: Sunucuda bir öğenin değeri Z olsun. Siz bu değeri iyimser olarak X'e güncellersiniz. İsteğiniz devam ederken başka bir kullanıcı aynı öğeyi sunucuda Y olarak günceller. İsteğiniz sunucuya ulaşır ve sunucu isteği reddeder (çakışma). Geri alma hedefiniz Z'dir, ancak sunucunun mevcut durumu Y'dir. Z'yi geri yüklemek Y'nin üzerine yanlış biçimde yazılmasına neden olur.

Güncellemeler için en güvenli geri alma stratejisi, yerel olarak saklanan bir anlık görüntüyü geri yüklemek yerine herhangi bir değişiklik işlemi hatasında öğeyi sunucudan yeniden getirmektir. Böylece diğer kullanıcıların eşzamanlı olarak yaptığı değişikliklerden bağımsız biçimde, yetkili sunucu durumunu görüntülediğiniz garanti edilir. Yeniden getirme daha yavaştır ancak her zaman doğru sonucu verir.

İyi tasarlanmış bir API, iyimser bir güncelleme eşzamanlı bir değişiklik nedeniyle başarısız olduğunda HTTP 409 Çakışması döndürür. Yanıt gövdesi genellikle sunucudaki mevcut durumu içerir. Hata işleyiciniz 409'u algılamalı, yerel durumu sunucudaki mevcut değerle güncellemek için yanıt gövdesini kullanmalı ve kullanıcıya değişikliklerinin kaydedilmediğini bildirmelidir.

İdempotent bir değişiklik işlemi birden çok kez uygulandığında aynı sonucu üretir. Değişiklik işlemlerini idempotent olacak şekilde tasarlamak (POST yerine PUT kullanmak, kaynağın tamamını göndermek ve idempotentlik anahtarları kullanmak), değişikliği iki kez uygulama riski olmadan başarısızlık durumunda yeniden denemeyi güvenli hâle getirir. Bu, geri alma mantığını önemli ölçüde basitleştirir.

Gönder düğmesine art arda iki kez tıklanması, aynı değişiklik işleminin iki kez çalıştırılmasına neden olabilir. Bunu bir isSubmitting bayrağıyla önleyin: değişiklik işlemi başladığında bu bayrağı true olarak ayarlayın, işlem tamamlandığında (başarılı veya başarısız olmasından bağımsız olarak) sıfırlayın. isSubmitting true olduğunda tetikleyici öğesini devre dışı bırakın. Böylece kullanıcı arayüzü düzeyinde yinelenen değişiklik işlemleri ortadan kaldırılır.

Sunucu tarafında tekilleştirme yapmak için her değişiklik işlemi isteğine benzersiz bir Idempotency-Key üst bilgisi ekleyin. Kullanıcı işlemi başlattığında bu anahtarı crypto.randomUUID() ile üretin. Sunucu, yinelenen anahtarları algılar ve işlemi yeniden uygulamadan ilk istekteki yanıtın aynısını döndürür.

Bir değişiklik işlemi devam ederken iyimser durumun henüz doğrulanmadığını gösteren zarif bir belirteç sunabilirsiniz: küçük, titreşen bir nokta, "Kaydediliyor..." metni veya öğenin saydamlığını azaltma. Bu, etkileşimi engellemeden belirsizliği ifade eder. İşlem başarılı olduğunda veya başarısızlık durumunda geri alma yapıldığında belirteci kaldırın.

Geri alma mantığındaki beklenmeyen hatalar (örneğin durum geri yüklenirken tanımsız bir değerin özelliklerine erişilmesi) bileşenin çökmesine neden olabilir. Geri alma işlemlerinin yoğun kullanıldığı bileşenleri bir hata sınırıyla sarın; böylece kritik geri alma hataları boş ekran yerine düzgün bir hata arayüzü gösterir. Hata ayıklama için bu hataları günlüğe kaydedin.

Güvenilir bir çakışma algılama stratejisi olarak her değişiklik işlemine bir sürüm numarası veya ETag ekleyin. Sunucu, istemci tarafından gönderilen sürümü kendi mevcut sürümüyle karşılaştırır. Sürümler farklıysa (başka bir güncelleme gerçekleşmişse) 409 döndürür. Bu, iyimser eşzamanlılık denetimidir: çakışma olmadığını varsayar, ancak gerçekleştiğinde bunu algılarsınız.

Ağ hatalarını benzetmek zor olduğu için geri alma mantığı çoğu zaman sınanmaz. Sınamalarda hata yanıtları döndürmek için Sahte Servis Çalışanı (MSW) gibi araçlar kullanın. Şu durumlar için açık sınamalar yazın: 409 Çakışması işleme, ağ zaman aşımında geri alma, art arda iki kez tıklamayı tekilleştirme ve başarısızlık sonrasında durum tutarlılığı. Hatalar genellikle bu uç durumlarda gizlenir.

İyi tasarlanmış bir API, iyimser bir güncelleme başka bir kullanıcının eşzamanlı değişikliği nedeniyle başarısız olduğunda hangi HTTP durum kodunu döndürür?

Güncelleme işlemini geri almak, ekleme veya silme işlemini geri almaktan daha karmaşıktır; eski anlık görüntü sorunlarını önlemek için hata durumunda her zaman yeniden getirme yapın. HTTP 409 Çakışması, iyimser eşzamanlılık hatalarını belirtir; sunucunun mevcut durumunu geri yüklemek için yanıt gövdesini kullanın. Güvenli yeniden denemeler için değişiklik işlemlerini idempotent olacak şekilde tasarlayın. isSubmitting ve sunucu tarafındaki idempotentlik anahtarlarıyla işlemlerin iki kez çalıştırılmasını önleyin. Hataları benzetmek için MSW kullanarak geri alma yollarını açıkça sınayın.