Sorun: Bekleyen istek ve kontrolsüz tekrar
Bir API istemcisi, karşı sunucu yanıt vermediğinde sınırsız bekleyebilir. Timeout eklenmiş olsa bile her hatada tekrar denemek; özellikle POST gibi yan etkili işlemlerde aynı siparişin iki kez oluşturulmasına yol açabilir. Küçük bir PHP örneği:
Bu kodda toplam bekleme süresi çok uzayabilir. 500, 429, bağlantı kopması ve kalıcı bir 400 hatası aynı şekilde ele alınır. Ayrıca POST isteğinin güvenle tekrar edilip edilemeyeceği bilinmiyor. AI incelemesinden, yalnızca “retry sayısını azalt” önerisi almak yeterli değildir; hata sınıfları ve işlemin idempotent olup olmadığı ayrıca incelenmelidir.
AI ile inceleme ve düzeltme
İnceleme isteğinde endpoint’in yan etkisini, kabul edilen HTTP durum kodlarını ve beklenen toplam süreyi açıkça belirtmek daha yararlıdır: “Bu PHP istemcisinde geçici ağ hataları ile kalıcı 4xx hatalarını ayır. En fazla üç deneme ve toplam 10 saniyelik süre sınırı öner. POST işleminin idempotency anahtarı olmadan tekrar edilmesindeki riski ayrıca belirt.”
Örneğin daha kontrollü bir taslak şöyle olabilir:
Buradaki sayılar her API için evrensel doğru değildir. Timeout değeri API’nin beklenen yanıt süresine, retry listesi ise dokümante edilen hata davranışına göre belirlenmelidir. 429 yanıtında sunucu Retry-After bilgisi veriyorsa bu değer de güvenli bir üst sınırla değerlendirilmelidir. Idempotency desteği olmayan yan etkili bir endpoint’te otomatik tekrar yerine işlemin durumunu sorgulamak daha doğru olabilir.
Doğrulama adımları
Bir API istemcisi, karşı sunucu yanıt vermediğinde sınırsız bekleyebilir. Timeout eklenmiş olsa bile her hatada tekrar denemek; özellikle POST gibi yan etkili işlemlerde aynı siparişin iki kez oluşturulmasına yol açabilir. Küçük bir PHP örneği:
function createInvoice(array $payload): array
{
for ($attempt = 0; $attempt < 5; $attempt++) {
$response = sendHttpRequest('/invoices', $payload, 30);
if ($response->statusCode() === 200) {
return $response->json();
}
}
throw new RuntimeException('Invoice request failed');
}Bu kodda toplam bekleme süresi çok uzayabilir. 500, 429, bağlantı kopması ve kalıcı bir 400 hatası aynı şekilde ele alınır. Ayrıca POST isteğinin güvenle tekrar edilip edilemeyeceği bilinmiyor. AI incelemesinden, yalnızca “retry sayısını azalt” önerisi almak yeterli değildir; hata sınıfları ve işlemin idempotent olup olmadığı ayrıca incelenmelidir.
AI ile inceleme ve düzeltme
İnceleme isteğinde endpoint’in yan etkisini, kabul edilen HTTP durum kodlarını ve beklenen toplam süreyi açıkça belirtmek daha yararlıdır: “Bu PHP istemcisinde geçici ağ hataları ile kalıcı 4xx hatalarını ayır. En fazla üç deneme ve toplam 10 saniyelik süre sınırı öner. POST işleminin idempotency anahtarı olmadan tekrar edilmesindeki riski ayrıca belirt.”
Örneğin daha kontrollü bir taslak şöyle olabilir:
function createInvoice(array $payload, string $requestId): array
{
$deadline = microtime(true) + 10.0;
$maxAttempts = 3;
for ($attempt = 1; $attempt <= $maxAttempts; $attempt++) {
$remaining = $deadline - microtime(true);
if ($remaining <= 0) {
break;
}
try {
$response = sendHttpRequest(
'/invoices',
$payload,
min(3.0, $remaining),
['Idempotency-Key' => $requestId]
);
if ($response->statusCode() === 200 || $response->statusCode() === 201) {
return $response->json();
}
if (!in_array($response->statusCode(), [408, 429, 500, 502, 503, 504], true)) {
throw new RuntimeException('Permanent API error');
}
} catch (TransientNetworkException $e) {
// Bir sonraki denemeye geçilebilir.
}
if ($attempt < $maxAttempts) {
$delay = min(0.25 * (2 ** ($attempt - 1)), 2.0);
usleep((int) ($delay * 1000000));
}
}
throw new RuntimeException('API request exceeded retry or deadline limit');
}Buradaki sayılar her API için evrensel doğru değildir. Timeout değeri API’nin beklenen yanıt süresine, retry listesi ise dokümante edilen hata davranışına göre belirlenmelidir. 429 yanıtında sunucu Retry-After bilgisi veriyorsa bu değer de güvenli bir üst sınırla değerlendirilmelidir. Idempotency desteği olmayan yan etkili bir endpoint’te otomatik tekrar yerine işlemin durumunu sorgulamak daha doğru olabilir.
Doğrulama adımları
- Yapay gecikmeyle yanıt veren sahte sunucuda tek isteğin toplam süresinin deadline’ı aşmadığını ölçün.
- İlk iki denemede 503, son denemede 201 dönen senaryoda en fazla üç istek gönderildiğini doğrulayın.
- 400 veya 401 yanıtında tekrar yapılmadığını test edin.
- Bağlantı hatasının sınırlı sayıda tekrar edildiğini ve sonunda anlamlı bir hata döndüğünü kontrol edin.
- Aynı Idempotency-Key ile tekrar gönderilen isteğin sağlayıcı tarafından ikinci kaynak oluşturmamasını doğrulayın; bunu sağlayıcı dokümantasyonu veya test ortamı olmadan varsaymayın.
- Günlüklerde istek gövdesi, token ve kişisel verilerin yazılmadığını inceleyin.