| Kod | Anlam | Açıklama |
|---|---|---|
| 200 | OK | İstek başarılı. |
| 201 | Created | Yeni kaynak oluşturuldu. |
| 204 | No Content | Başarılı yanıt; gövde yok. |
| 301 | Moved Permanently | Kalıcı yönlendirme. |
| 302 | Found | Geçici yönlendirme. |
| 304 | Not Modified | Koşullu istekte kaynak değişmemiş. |
| 400 | Bad Request | İstek biçimi veya girdi kabul edilmedi. |
| 401 | Unauthorized | Kimlik doğrulama gerekiyor veya geçersiz. |
| 403 | Forbidden | Erişim reddedildi. |
| 404 | Not Found | Kaynak bulunamadı. |
| 409 | Conflict | İstek mevcut durumla çakışıyor. |
| 422 | Unprocessable Content | Biçim okunuyor, içerik kuralı uymuyor. |
| 429 | Too Many Requests | Hız sınırı uygulanıyor. |
| 500 | Internal Server Error | Sunucuda beklenmeyen hata. |
| 502 | Bad Gateway | Ağ geçidi geçersiz yanıt aldı. |
| 503 | Service Unavailable | Sunucu geçici olarak hizmet veremiyor. |
Kod sınıfları
1xx bilgilendirme, 2xx başarı, 3xx yönlendirme, 4xx istemci isteği problemi ve 5xx sunucu sorunu sınıflarıdır.
401 kimlik doğrulama gereksinimini, 403 ise erişimin reddedilmesini gösterir. Gerçek neden için API sözleşmesi ve yanıt gövdesine bakın.
Yönlendirme ve fetch
Kalıcı ve geçici yönlendirme önbellek davranışını etkiler. Canonical hedefi ve zinciri kontrol edin.
Fetch, 404/500 yanıtlarında her zaman ağ hatası fırlatmaz. response.ok ve response.status değerlerini inceleyin.
Hata ayıklama
Network sekmesinde yöntem, URL, status, başlık ve gövdeyi birlikte değerlendirin.
Ekran görüntüsü paylaşırken token ve kişisel verileri maskeleyin. Başvuru tablosu kök nedeni tek başına bulmaz.
İstek sırasıyla teşhis
Önce isteğin gerçekten gönderildiğini, hedef URL’yi ve kullanılan HTTP yöntemini doğrulayın. Ardından kimlik doğrulama, istek gövdesi, yanıt başlıkları ve yanıt gövdesini kontrol edin.
Tarayıcıda CORS veya DNS gibi ağ katmanı hataları HTTP yanıt kodu üretmeden başarısız olabilir. Bir status kodu varsa onu isteğin hangi katmanında oluştuğuyla birlikte okuyun.
Yeniden deneme ve güvenli davranış
429 veya geçici 503 yanıtlarında Retry-After başlığını kontrol edin ve sınırlı gecikmeli yeniden deneme uygulayın. Her hatayı anında tekrar göndermek sunucu yükünü artırabilir.
Bir isteği yeniden denemeden önce işlemin tekrara dayanıklı olup olmadığını düşünün. Ödeme veya kaynak oluşturma gibi yan etkili isteklerde tekrarın yeni kayıt ya da çift işlem üretmeyeceğini garanti edin.