Retry-After saniye ya da HTTP tarihi olarak ayrıştırılır. Her deneme için üstel gecikme üst sınırla kısıtlanır, deterministik jitter eklenir ve sunucunun bildirdiği en erken zamanın önüne geçilmez.
332
Veri ve geliştirici
Retry-After ve Geri Çekilme Planlayıcı
HTTP Retry-After değerini saniye veya HTTP tarihi olarak yorumlar; güvenli yöntem, deneme sayısı, taban gecikme, üst sınır ve deterministik jitter ile her yeniden denemenin en erken zamanını hesaplar. Ağ isteği yapmaz ve isteği kendisi tekrar göndermez.
✓ Ücretsiz✓ Üyelik yok✓ Tarayıcı içinde
KISA CEVAP
Bu araç ne yapar?
429/503 yanıtları için sunucu bekleme süresi, üstel geri çekilme, jitter ve üst sınırı görünür bir zaman çizelgesine dönüştürün.
UYGULAMA VE KARAR REHBERİ
Retry-After ve Geri Çekilme Planlayıcı: yöntem ve kullanım
HTTP Retry-After değerini saniye veya HTTP tarihi olarak yorumlar; güvenli yöntem, deneme sayısı, taban gecikme, üst sınır ve deterministik jitter ile her yeniden denemenin en erken zamanını hesaplar. Ağ isteği yapmaz ve isteği kendisi tekrar göndermez.
HTTP yöntemi, 429 veya 503 yanıtı, Retry-After değeri, deneme sayısı, taban gecikme, üst sınır ve jitter yüzdesi Biçimi önce kişisel veri içermeyen küçük bir örnekle doğrulayın.
deneme numarası, hesaplanan bekleme süresi, en erken yeniden deneme zamanı ve güvenli olmayan yöntem uyarısı içeren zaman çizelgesi
Uygulama adımları
- Örneği yükleyin veya anlaşılır alanları kendi senaryonuzla doldurun.
- Denetimi cihazınızda çalıştırın; ölçümleri, uyarıları ve önerilen düzeltmeleri birlikte inceleyin.
- Sonucu gerçek hedef ortamda doğrulayın ve karar kaydına varsayımları ekleyin.
ilk beklemenin Retry-After değerinden kısa olmadığını, gecikmelerin üst sınırı aşmadığını ve aynı girdinin aynı jitter çizelgesini verdiğini kontrol etme
Bu plan istek göndermez ve işlemin idempotent olduğunu kanıtlamaz. POST/PATCH gibi yan etkili çağrıları otomatik tekrar etmeden önce idempotency anahtarı, sunucu sözleşmesi ve gerçek saat kaymasını doğrulayın.
Uygun kullanım alanları
- API istemci davranışı tasarlama
- 429 yük testini belgeleme
- 503 bakım penceresi planlama
Uygulamalı karar kaydı
Pratik senaryo: API istemci davranışı tasarlama. 429/503 yanıtları için sunucu bekleme süresi, üstel geri çekilme, jitter ve üst sınırı görünür bir zaman çizelgesine dönüştürün.
GET, 429, Retry-After 8 saniye, 5 deneme, 500 ms taban, 30.000 ms üst sınır ve %20 jitter girin; ardından yöntemi POST yaparak durma uyarısını karşılaştırın.
Kabul kaydı: ilk beklemenin Retry-After değerinden kısa olmadığını, gecikmelerin üst sınırı aşmadığını ve aynı girdinin aynı jitter çizelgesini verdiğini kontrol etme. Sonuç kartındaki sayılar ve uyarılar, kaydedilen örnekle birlikte saklanır.
Bu durumda yayınlamayın: Bu plan istek göndermez ve işlemin idempotent olduğunu kanıtlamaz. POST/PATCH gibi yan etkili çağrıları otomatik tekrar etmeden önce idempotency anahtarı, sunucu sözleşmesi ve gerçek saat kaymasını doğrulayın.
DERİNLEŞTİRİN
Bu araçla ilgili rehberler
Dayanıklı API Retry ve Webhook Teslimi: 429'dan İdempotency Kanıtına
Retry-After, üstel geri çekilme, jitter, teslim kimliği ve zaman sırasını tek bir sınanabilir hata kurtarma sözleşmesinde birleştirin.
Rehberi oku →API Hata, Kota ve Yönlendirme Sözleşmelerini Birlikte Tasarlama
Başarılı yanıt kadar hata zarfını, geri çekilmeyi, kapasite sınırını ve URL geçişini de sürümlenebilir ürün davranışı olarak ele alın.
Rehberi oku →ARAÇ HAKKINDA
Sık sorulan sorular
Retry-After ve Geri Çekilme Planlayıcı hangi girdiyi kabul eder?+
HTTP yöntemi, 429 veya 503 yanıtı, Retry-After değeri, deneme sayısı, taban gecikme, üst sınır ve jitter yüzdesi GET, 429, Retry-After 8 saniye, 5 deneme, 500 ms taban, 30.000 ms üst sınır ve %20 jitter girin; ardından yöntemi POST yaparak durma uyarısını karşılaştırın.
Retry-After ve Geri Çekilme Planlayıcı çıktısında ne görürüm?+
deneme numarası, hesaplanan bekleme süresi, en erken yeniden deneme zamanı ve güvenli olmayan yöntem uyarısı içeren zaman çizelgesi Kabul kaydı: ilk beklemenin Retry-After değerinden kısa olmadığını, gecikmelerin üst sınırı aşmadığını ve aynı girdinin aynı jitter çizelgesini verdiğini kontrol etme. Sonuç kartındaki sayılar ve uyarılar, kaydedilen örnekle birlikte saklanır.
Retry-After ve Geri Çekilme Planlayıcı çıktısını nasıl doğrulamalıyım?+
ilk beklemenin Retry-After değerinden kısa olmadığını, gecikmelerin üst sınırı aşmadığını ve aynı girdinin aynı jitter çizelgesini verdiğini kontrol etme Bu durumda yayınlamayın: Bu plan istek göndermez ve işlemin idempotent olduğunu kanıtlamaz. POST/PATCH gibi yan etkili çağrıları otomatik tekrar etmeden önce idempotency anahtarı, sunucu sözleşmesi ve gerçek saat kaymasını doğrulayın.
Retry-After ve Geri Çekilme Planlayıcı girdiyi bir sunucuya gönderir veya kaydeder mi?+
Araç girdisi etkin sekmede işlenir. İş İstasyonu’na kaydetme veya başka bir araca aktarma ayrı bir seçimdir. Tarayıcı eklentileri ve paylaşılan cihazlar ayrıca değerlendirilmelidir; gizlilik sayfası reklam ve ağ bağlantılarını açıklar.