JavaScript’te HTTP isteği oluşturmanın iki yolu vardır; bu konu hakkında bitmek bilmeyen tartışmalar sürer ve bu tartışmalar genellikle en önemsiz boyutlar üzerinden yürütülür.
Paket boyutu, sözdiziminin zarafeti, bir bağımlılığın gerekçeli olup olmadığı — bunlar tercihlerdir ve makul insanlar bu konularda farklı görüşlere sahip olabilir. Bir fark ise tercih meselesi değildir ve üretim kodunda gerçek hatalara yol açar: fetch, sunucu bir hata durumu döndürdüğünde vaadini reddetmez. 404 hatası çözülür. 500 hatası çözülür. .catch() adresiniz asla çalışmaz ve kod, her şey yolunda gitmiş gibi ilerler.
Bu, bir tuhaflıktan ziyade belgelenmiş bir davranıştır ve her şeyden önce anlaşılması gereken bir konudur.
Biz Geonode şirketiyiz ve proxy satıyoruz, bu nedenle konuyla ilgili bir not eklemek istiyoruz: Bu ikisi arasında Node'daki proxy desteği konusunda gerçek ve yeterince belgelenmemiş bir fark vardır ve bu durum kullanıcıları sık sık yanıltmaktadır. Node'daki yerel fetch, standart proxy ortam değişkenlerini algılamaz; bu da, onun curl gibi davrandığını varsayan hemen hemen herkesi şaşırtır. Bunun kendine ait bir bölümü vardır ve istekleri bir proxy üzerinden yönlendirmiyorsanız bu bölümü tamamen atlayabilirsiniz — çoğu kişi de öyle yapmalıdır.
Eski bağlantıları takip eden herkesi ilgilendirdiği için küçük bir not: Axios’un belgeleri taşınmıştır. axios-http.com artık axios.rest adresine yönlendiriyor. Eski etki alanına yönlendiren yer imleri ve Stack Overflow cevapları, yönlendirme sayesinde hâlâ çalışıyor, ancak resmi konum değişmiştir.
Aşağıda davranışlarla ilgili her şey, kimsenin hafızasına dayanmak yerine MDN ve Axios’un kendi belgelerinden alınmıştır.
Gerçek Hatalara Neden Olan Fark
Buradan başlayın, çünkü bu, kişisel tercih meselesi olmayan tek farktır.
MDN'nin Söyledikleri
Doğrudan belgelerden alıntı:
"fetch()
'i içeren bir promise, yalnızca istek başarısız olduğunda (örneğin, hatalı biçimlendirilmiş istek URL'si veya ağ hatası nedeniyle) reddedilir. fetch()
vaadi, sunucu hataları belirten HTTP durum kodlarıyla (404
, 504
vb.) yanıt verirse reddedilmez. Bunun yerine, then()
işleyicisi Response.ok
ve/veya Response.status
özelliklerini kontrol etmelidir."
reddedilmez ifadesindeki vurgu MDN'ye aittir.
Bunun Pratikte Anlamı
// Looks correct. Is not.
try {
const res = await fetch('/api/user/999');
const user = await res.json();
showUser(user); // runs on a 404
} catch (err) {
showError(err); // never runs on a 404
}
Sunucu, hata gövdesi içeren bir 404 yanıtı döndürdü. fetch
sorunsuz bir şekilde çözümlendi. res.json()
hata nesnesini ayrıştırdı. showUser
, kullanıcı olmayan bir şey aldı ve hata daha sonra, başka bir yerde, tanımlanmamış bir özellik hakkında kafa karıştırıcı bir hata olarak ortaya çıktı.
Doğru sürüm:
try {
const res = await fetch('/api/user/999');
if (!res.ok) {
throw new Error(`HTTP ${res.status}`);
}
const user = await res.json();
showUser(user);
} catch (err) {
showError(err);
}
Üç satır daha eklendi ve bunlar yazdığınız her bir istek için zorunludur.
Axios'un Davranışı
Axios, varsayılan olarak 2xx aralığı dışındaki durum kodlarını reddeder. Buna eşdeğer kodta durum kontrolüne gerek yoktur:
try {
const { data } = await axios.get('/api/user/999');
showUser(data);
} catch (err) {
showError(err); // runs on a 404
}
Hangi Davranış Doğrudur
Her ikisi de savunulabilir ve bu konudaki anlaşmazlık felsefi niteliktedir.
fetch
, aktarımın başarılı olduğu görüşündedir — sunucuya ulaşıldı, sunucu yanıt verdi ve yanıt bozulmadan geldi. 404, bir soruya verilen geçerli bir yanıttır, soruyu soramama durumu değildir. Reddetmek, aktarım hatasını uygulama semantiğiyle karıştırmak anlamına gelir. Bu arada, bu tam olarak curl'ün de tutumudur; curl'de de 404, sıfır çıkış kodu üretir.
Axios ise, çoğu çağrı yapanın 4xx veya 5xx kodlarını bir hata olarak değerlendirdiği için, bunların da bir hata gibi davranması gerektiği görüşündedir.
Pratikteki gerçek şu ki, fetch
'daki model daha doğrudur ancak hataya daha açıktır; çünkü her çağrıda disiplin gerektirir ve bu disiplin bozulduğunda sizi uyaran hiçbir şey yoktur.
Fetch Nedir ve Maliyeti Nedir
Avantajları ve eksiklikleriyle birlikte bu standart.
Avantajları
Yerleşik bir özelliktir. Bağımlılık yok, kurulum yok, paket maliyeti yok, denetlenecek tedarik zinciri yok. Tarayıcılarda ve modern Node’da zaten mevcuttur.
Bir standarttır. Yönünü değiştirebilecek, terk edilebilecek veya kendi takvimine göre uyumsuz değişiklikler getirebilecek bir proje tarafından sürdürülmek yerine, standart olarak tanımlanmıştır.
Temeldir. Birçok üst düzey kütüphane, Fetch'i saran sarmalayıcılardır; dolaylıyfetch'i anlamak, bunların ne yaptığını anlamak demektir.
Akış işlemeyi iyi yönetir. Response.body okunabilir bir akıştır; bu da büyük yanıtların aşamalı olarak işlenmesini doğal hale getirir.
Neler Yapmaz
Bunlar, sizin kendiniz doldurmanız gereken boşluklardır ve bunların sayısı, Axios'u kullanmanın asıl gerekçesidir.
Otomatik JSON yok. .json() işlevini çağırırsınız; bu, başka bir await işlemidir ve yanıt JSON değilse (örneğin, yanlış yapılandırılmış bir sunucudan alacağınız gibi bir HTML hata sayfası) hata oluşabileceği başka bir noktadır.
Durum reddi yok. Yukarıda ele alınmıştır.
Varsayılan olarak zaman aşımı yok. Bir fetch süresiz olarak takılabilir. AbortSignal.timeout(), modern ortamlarda bir zaman aşımı sağlar, ancak bu isteğe bağlıdır ve unutulması kolaydır — ki bu, takılmanın en kötü sonuçlara yol açtığı durumlarda en çok önem arz eder.
Aracılar yok. Otorizasyon jetonunu, korelasyon kimliğini veya merkezi günlüğü ekleyebileceğiniz bir yer yoktur. Ya her çağrıda bunu tekrarlamanız gerekir ya da bir sarmalayıcı yazmanız gerekir; ancak sarmalayıcı yazmak, insanların yanlışlıkla kendi kötü Axios'larını oluşturmalarına neden olur.
Yükleme ilerlemesi yok. İndirme ilerlemesi yanıt akışı aracılığıyla mümkündür; yükleme ilerlemesi ise o kadar basit değildir.
Otomatik istek gövdesi serileştirmesi yok. Her seferinde JSON.stringify adresini çağırıp içerik türünü kendiniz ayarlamanız gerekir.
Node’da proxy yapılandırması yok. Aşağıda buna ayrılmış bir bölüm bulunmaktadır.
Dürüst Özet
fetch, iyi tasarlanmış, düşük seviyeli bir temel bileşendir. Eksiklikleri kasıtlıdır — bir standart, minimal ve tarafsız olmalıdır.
Asıl soru, bunun iyi olup olmadığı değildir. Asıl soru, eksik katmanı kendiniz uygulamak isteyip istemediğiniz ve uyguladığınız sürümün, geniş bir kullanıcı tabanına sahip ve sınır durumlarını tespit eden bir proje tarafından sürdürülen sürümden daha iyi olup olmayacağıdır.
Axios Size Neler Sunuyor?
Kendi belgelerine göre, özellik listesi en önemli argüman.
Çevreler arasında tutarlı bir arayüze sahip, tarayıcı ve Node için ayrı paketler sunan Promise tabanlı HTTP istemcisi.
İstek ve yanıtlar için ara alıcılar; bu, en değerli ve aynı zamanda en temiz şekilde kopyalanması en zor olan özelliktir. Bir kez kimlik doğrulama başlığı ekleyin, 401 yenilemeyi bir kez işleyin, günlük kaydı eklemeyi bir kez yapın — ve uygulamadaki her istek bunu devralır.
Her iki yönde de otomatik JSON işleme. İstek gövdeleri serileştirilir ve içerik türü belirlenir; yanıtlar response.data biçimine ayrıştırılır.
2xx dışındaki durum kodlarında reddetme içeren hata işleme.
Belgelerde, süresiz istek takılmalarını önleyen olarak açıklanan zaman aşımı yapılandırması. Her çağrı için ayrı bir iptal denetleyicisi yerine tek bir yapılandırma değeri.
İşlem halindeki isteklerin iptali.
fetch'ın doğrudan sunmadığı, hem yüklemeler hem de indirmeler için ilerleme takibi.
Yerleşik XSRF koruması.
Dosya gönderimi ve çok parçalı form verileri sizin için yönetilir.
Hız sınırlama ve istek kısıtlama.
Varsayılan ayarlara sahip örnekler; böylece temel URL, başlıklar ve zaman aşımı ayarlarına sahip yapılandırılmış bir istemci bir kez oluşturulup her yere aktarılabilir.
Maliyetler
Bir bağımlılık. Yüklemeniz, güncel tutmanız ve denetlemeniz gereken bir şey. Güvenlik bilincinin yüksek olduğu bir ortamda bu, teorik olmaktan çok gerçek bir maliyettir.
Paket boyutu. Küçük bir ön uç için anlamlı, büyük bir uygulama veya sunucu tarafındaki herhangi bir şey için ise önemsizdir.
Öğrenilmesi gereken başka bir soyutlama ve zaman zaman altta yatan platformdan sizi şaşırtacak şekilde farklı davranan bir soyutlama.
Adil Bir Bakış Açısı
Axios, bu davranışlara ihtiyaç duyduğunda çoğu kişinin fetch üzerine geliştirdiği şeye kabaca benziyor — ancak Axios zaten yazılmış, hata ayıklaması yapılmış ve sizin düşünmediğiniz durumları da hallediyor.
Bunların hiçbirine ihtiyacınız yoksa, bu gereksiz bir bağımlılıktır.
Yan Yana
| fetch | Axios |
|---|
| Kurulum | Yerleşik | npm install |
| 404/500 hatalarında reddetme | Hayır | Evet |
| JSON ayrıştırma | Manuel .json() | Otomatik |
| İstek gövdesi serileştirme | Manuel | Otomatik |
| Zaman aşımı | AbortSignal.timeout() | Yapılandırma seçeneği |
| Engelleyiciler | Hayır | Evet |
| Yükleme ilerlemesi | Basit değil | Evet |
| İndirme ilerlemesi | Yanıt akışı yoluyla | Evet |
| İptal | AbortController | Yerleşik |
| XSRF koruması | Manuel | Yerleşik |
| Varsayılan ayarlara sahip örnekler | Hayır | Evet |
| Node'da proxy yapılandırması | Hayır | Evet |
| Akış | Mükemmel | Daha sınırlı |
| Paket maliyeti | Sıfır | Küçük ama sıfırdan farklı |
Aynı İstek, İki Farklı Yöntem
// fetch, written correctly
const res = await fetch('https://api.example.com/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': `Bearer ${token}`
},
body: JSON.stringify({ name: 'Alice' }),
signal: AbortSignal.timeout(5000)
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
// Axios
const { data } = await axios.post(
'https://api.example.com/users',
{ name: 'Alice' },
{ headers: { Authorization: `Bearer ${token}` }, timeout: 5000 }
);
Her ikisi de doğrudur. fetch sürümü on bir satır uzunluğundayken Axios'unki beş satırdır ve aradaki fark, tek seferlik bir yapılandırma yerine her çağrıda hatırlamanız gereken unsurlardan ibarettir.
Kararı Belirleyen İki Satır
404/500 hatalarında reddetme ve Node'da proxy yapılandırması, bir aracın diğerinin yaptığını doğrudan yapamadığı tek satırlardır. Geri kalanı standart kod parçalarıdır ve standart kod parçaları imkansızlık değil, bir maliyettir.
Standart Kod Vergisi
Asıl karşılaştırma, bir fetch
çağrısı ile bir axios
çağrısı arasında yapılmaz. Her ikisini de kullanan kod tabanları arasında yapılır.
Herkesin Eninde Sonunda Yazdığı Şey
Durum kontrolünü, zaman aşımını ve JSON ayrıştırmasını üçüncü veya dördüncü kez tekrarladıktan sonra şunu yazarsınız:
async function request(url, options = {}) {
const res = await fetch(url, {
...options,
headers: {
'Content-Type': 'application/json',
...(token && { Authorization: `Bearer ${token}` }),
...options.headers
},
signal: options.signal ?? AbortSignal.timeout(options.timeout ?? 10000)
});
if (!res.ok) {
const body = await res.text();
throw new HttpError(res.status, body);
}
return res.status === 204 ? null : res.json();
}
Bu, makul ve oldukça iyi bir sarmalayıcıdır. Aynı zamanda, şüphesiz, küçük bir Axios'tur.
Birisi Fark Edene Kadar Sarmalayıcının Başa Çıkamayacağı Şeyler
Geri çekme ile yeniden deneme. Birden fazla çağrı aynı anda başarısız olduğunda, istek seli olmadan 401 hatasında token yenileme. JSON yerine HTML döndüren istekler. Gövdesiz 204 yanıtları. İç içe geçmiş çağrılar aracılığıyla yayılan iptal. Yükleme ilerlemesi. JSON dışındaki içerik türleri. İzleme için korelasyon kimlikleri.
Her biri küçük bir eklemedir. Birlikte bir kütüphane oluştururlar ve sizin yazacağınız sürüm, halihazırda binlerce kişinin kullandığı sürümden daha az test edilmiş olacaktır.
Kendiniz Yazmak Ne Zaman Doğru Bir Seçimdir?
Bundan çok azına ihtiyacınız olduğunda. Tek bir API’ye yönelik birkaç GET isteği. Yukarıdaki sarmalayıcı otuz satırlık ve tamamen size ait.
Paket boyutu gerçekten önemli olduğunda. Her kilobaytın önemi büyük olan, performans açısından kritik bir sayfa.
Bağımlılıklar maliyetli olduğunda. Her paketin incelenmesi gereken ortamlar.
Platformu anlamak istediğinizde. Meşru bir neden ve bu anlayış aktarılabilir.
Ne Zaman Doğru Değildir
Üçüncü sarmalayıcı yinelemesindeyseniz, kod tabanının farklı kısımlarında farklı sarmalayıcılar varsa veya yeniden deneme mantığı ekliyorsanız. Bu noktada, bir kütüphaneyi yan proje olarak sürdürüyorsunuz demektir ve kaçındığınız bağımlılık, kendi oluşturduğunuzdan daha ucuzdur.
Paket Boyutu ve Düğüm Sorunu
Cevabı etkileyen iki bağlamsal faktör.
Tarayıcıda
Axios, paketinizin boyutunu artırır. Bunun önemli olup olmadığı, tamamen ne geliştirdiğinize bağlıdır.
Yükleme süresinin ürünün kendisi olduğu bir açılış sayfası veya bir widget — fetch kullanın. Her kilobayt önemlidir ve istek kalıpları genellikle o kadar basittir ki, hazır kodlar önemsiz kalır.
Zaten bir çerçeve ve bileşen kütüphanesi içeren büyük bir uygulama — marjinal maliyet önemsizdir ve interceptor desteği, baytların değerinden çok daha fazladır.
Dürüst olmak gerekirse, paket boyutu, insanların estetik bir tercihin teknik bir gerekçesini aradıklarında öne sürdükleri bir argümandır. Bu gerçek bir faktördür, ancak sık sık öne sürüldüğü kadar belirleyici değildir.
Node'da
Tamamen farklı bir hesaplama söz konusudur. Paket boyutu sunucuda önemsizdir, dolayısıyla Axios'a karşı öne sürülen ana argüman ortadan kalkar.
Modern Node sürümlerinde yerel fetch kullanılabilir ve iyi çalışır. Ancak sunucu tarafı kodları, genellikle fetch adresinde eksik olan şeylere ihtiyaç duyar: her şey için zaman aşımı, geri çekilme ile yeniden deneme, merkezi kimlik doğrulama yönetimi, giden çağrıların yapılandırılmış günlüğe kaydedilmesi ve — bir sonraki bölümde ele alınacağı üzere — proxy yapılandırması.
Dolayısıyla, denge tarayıcıdan çok sunucuda Axios lehine kayar; bu da argümanın genellikle ileri sürüldüğü şeklin tam tersidir.
Kimsenin Bahsetmediği Uzlaşma
İkisini de kullanabilirsiniz. Basit çağrılar için fetch, mekanizmaya ihtiyaç duyduğunuz yerlerde ise Axios. Bunu engelleyen hiçbir şey yoktur ve tutarlılık argümanı göründüğü kadar güçlü değildir.
Asıl sorun yaratan şey, tek bir kod tabanında bulunan ve her biri hataları biraz farklı şekilde işleyen üç farklı, kendi geliştirilmiş sarmalayıcıdır. Bu durum, her iki kütüphanenin de tutarlı bir şekilde kullanılmasından daha kötüdür ve şaşırtıcı sayıda projenin sonu bu şekilde olmaktadır.
Her İkisinde de Proxy'ler
Bu konu, bizim uzmanlık alanımız ve pek çok geliştirici için gerçekten kafa karıştırıcı bir öğleden sonranın kaynağıdır.
Kısa Özet
Node'daki yerel fetch, standart proxy ortam değişkenlerini okumaz. HTTP_PROXY ve HTTPS_PROXY ayarları, curl'den, çoğu HTTP kütüphanesinden ve neredeyse herkesin beklediğinin aksine hiçbir işe yaramaz.
Node'un global fetch'si undici üzerine kurulmuştur ve bir proxy üzerinden yönlendirme yapmak için bir dispatcher'ın açıkça belirtilmesi gerekir:
import { ProxyAgent, setGlobalDispatcher } from 'undici';
setGlobalDispatcher(new ProxyAgent('http://user:pass@proxy.example.com:8080'));
// now fetch goes through the proxy
const res = await fetch('https://example.com');
Ya da istek başına, dispatcher seçeneğini geçirerek.
Node'da Axios
Axios'ta proxy yapılandırma seçeneği vardır:
const res = await axios.get('https://example.com', {
proxy: {
protocol: 'http',
host: 'proxy.example.com',
port: 8080,
auth: { username: 'user', password: 'pass' }
}
});
SOCKS proxy'leri için veya daha hassas kontrol sağlamak amacıyla, genel yaklaşım httpAgent ve httpsAgent olarak geçirilen bir agent kütüphanesidir.
Tarayıcıda İkisi de Yapamaz
Zaman kazandırdığı için belirtmeye değer. Tarayıcıdaki JavaScript, proxy ayarlayamaz. Tarayıcı, sistemin veya bir uzantının yapılandırdığı ayarları kullanır ve hiçbir kütüphane bunu değiştiremez. Axios'un proxy seçeneği bir Node özelliğidir.
Tarayıcı tabanlı koddan proxy üzerinden istek göndermeniz gerekiyorsa, isteğin sizin kontrol ettiğiniz bir sunucudan geçmesi gerekir.
Hata Ayıklamada Dikkat Edilmesi Gereken Nokta
Node'da bir proxy "çalışmıyorsa", başka herhangi bir şeyi kontrol etmeden önce isteği hangi istemcinin gönderdiğini kontrol edin. Axios ile çalışan ancak fetch ile hata veren — ya da tam tersi — kodlar neredeyse her zaman bu durumdadır ve her ikisi de hata vermediği için bu durum fark edilmez. İstek basitçe doğrudan gönderilir.
Yapılandırdığınız istemci aracılığıyla bir adres raporlama uç noktasına istek göndererek ve döndürülen adresin proxy'ye ait olduğunu doğrulayarak bunu kontrol edin.
Ve Kendi Çıkarımıza Aykırı Olan Kısım
Çoğu sunucu tarafı HTTP çağrısı için proxy'ye hiç gerek yoktur. Erişim izni olan bir sunucudan, kimlik bilgilerine sahip olduğunuz bir API’yi çağırmak için ekstra bir şeye gerek yoktur — proxy gecikme, arıza noktası ve ek maliyet getirir. Proxy’ler, coğrafi kontrol ve adres başına kısıtlamaların geçerli olduğu yüksek hacimli veri toplama işlemlerinde yararlıdır. Bunun dışında, basit istemci daha iyi bir seçenektir.
Hangisini Seçmeli
Bir karar değil, bir karar listesi.
Ne zaman fetch kullanmalısınız?
Paket boyutu gerçekten kritik önem taşıyorsa. Açılış sayfaları, widget’lar, gömülü komut dosyaları.
İstekleriniz basitse. Birkaç GET isteği, asgari hata işleme, paylaşılan kimlik doğrulama yok.
Bağımlılık ekleyemiyorsanız veya her paketin incelenmesi gerekiyorsa.
Akışlarla çalışıyorsanız. fetch'ın akış modeli daha iyidir ve bu bir tercihden ziyade gerçek bir teknik avantajdır.
Platformu öğrenmek istiyorsanız. Bilgi aktarılır; Axios'a özgü bilgi aktarılmaz.
Axios'u şu durumlarda kullanın
Interceptor'lara ihtiyacınız varsa. Merkezi kimlik doğrulama, token yenileme, günlük kaydı, korelasyon kimlikleri. Bu en güçlü tek nedendir ve fetch'da buna tam olarak karşılık gelen bir şey yoktur.
Sunucuda çalışıyorsanız. Paket boyutu önemli değildir ve eksik olan özellikler tam da sunucu kodunun ihtiyaç duyduğu özelliklerdir.
Yükleme ilerleme durumuna ihtiyacınız varsa, ki bunu fetch ile yapmak kolay değildir.
Geniş bir kod tabanında çok çeşitli istekler gönderiyorsanız ve bir sarmalayıcı (wrapper) kullanmadan tutarlı bir davranış istiyorsanız.
Proxy yapılandırmasına ihtiyacınız varsa ve bir dispatcher oluşturmaktansa belgelenmiş bir seçeneği kullanmayı tercih ediyorsanız.
Hangisini Seçerseniz Seçin
Her zaman bir zaman aşımı ayarlayın. AbortSignal.timeout() veya Axios'un timeout seçeneği. Zaman aşımı ayarlanmamış bir istek süresiz olarak askıda kalabilir ve bu, JavaScript HTTP kodundaki en yaygın güvenilirlik kusurudur.
Durumu her zaman fetch ile kontrol edin. İstisnasız her çağrıda. res.ok iki kelimeden oluşur ve bunların eksikliği, bu makalenin başında bahsedilen hatadır.
Merkezileştirin. Tek bir sarmalayıcı veya tek bir yapılandırılmış Axios örneği. Tek bir kod tabanında üç tutarsız yaklaşım, her iki kütüphaneden de daha kötüdür ve bu, kimsenin kasıtlı olarak seçmeyeceği bir sonuçtur.
Kullanıcılar Ayrıca Şunları Soruyor
Axios ile fetch arasındaki temel fark nedir?
Hata işleme. MDN'ye göre, bir fetch promise "sunucu, hataları gösteren HTTP durum kodlarıyla yanıt verirse reddedilmez" — response.ok durumunu kendiniz kontrol etmeniz gerekir. Axios, 2xx dışındaki durum kodlarında reddedilir. Geri kalan her şey kolaylık sağlar: Axios, interceptor'lar, otomatik JSON, zaman aşımları, ilerleme ve proxy yapılandırması ekler.
Fetch artık yerleşik olduğu için Axios'a hala ihtiyaç var mı?
İhtiyacınıza bağlı. Basit istekler için hayır. Arayüzler, yükleme ilerleme durumu, örnek başına varsayılanlar veya Node proxy yapılandırması için Axios, hâlfetch'ın sunmadığı özellikler sunar ve bunları kendiniz yazmak, küçük bir kütüphaneyi sürdürmek anlamına gelir.
Neden fetch, 404 hatasında istisna atmaz?
Çünkü aktarım başarılı oldu — sunucuya ulaşıldı ve yanıt verildi. fetch, 404'ü başarısız bir istek olarak değil, geçerli bir yanıt olarak değerlendirir ve yalnızca ağ hataları veya hatalı biçimlendirilmiş URL'lerde reddedilir. Her çağrıda response.ok adresini kontrol edin.
Axios mu, fetch mi daha hızlıdır?
Tek bir istek için aradaki fark ihmal edilebilir düzeydedir; her ikisi de ağ hızına bağlıdır. Axios, az miktarda işlem yükü ekler ve tarayıcıda kütüphanenin kendisi için az miktarda indirme gerektirir.
fetch ile zaman aşımı nasıl ayarlanır?
AbortSignal.timeout(5000) Modern ortamlarda signal seçeneği olarak geçirilir veya kendi zamanlayıcınızı içeren bir AbortController kullanılır. Varsayılan bir zaman aşımı yoktur, bu nedenle zaman aşımı ayarlanmamış bir istek süresiz olarak askıda kalabilir.
Fetch, Node'da proxy'lerle çalışır mı?
Normal ortam değişkenleri yoluyla çalışmaz. Node'un global fetch değişkeni undici üzerine kurulmuştur ve HTTP_PROXY veya HTTPS_PROXY dosyalarını okumaz. ProxyAgent dağıtıcıyı, ya setGlobalDispatcher ile global olarak ya da istek bazında sağlamalısınız. Axios'ta ise bunun yerine proxy yapılandırma seçeneği bulunur.
Tarayıcıda fetch ile proxy kullanabilir miyim?
Hayır. Tarayıcı JavaScript'i proxy yapılandıramaz — tarayıcı, sistem veya uzantı ayarlarını kullanır. Herhangi bir kütüphanenin proxy seçeneği, yalnızca Node'a özgü bir özelliktir. Tarayıcıdan gelen proxy'li istekler, sizin kontrolünüz altındaki bir sunucudan geçmelidir.
Tek bir projede hem Axios hem de fetch kullanmalı mıyım?
Bu, başlı başına bir sorun değildir. Asıl sorunu yaratan, farklı hata davranışlarına sahip, tutarsız ve kendi geliştirdiğiniz birkaç sarmalayıcıdır. Hataların nasıl işlendiğindeki tutarlılık, isteği hangi kütüphanenin oluşturduğundan daha önemlidir.
Sonuç
Aradaki farklardan biri esaslıdır, geri kalanı ise tercihe bağlıdır.
fetch, HTTP hataları nedeniyle isteği reddetmez. MDN bunu açıkça belirtir: 404 veya 504 hataları çözümlenir ve response.ok veya response.status adreslerini kendiniz kontrol etmeniz gerekir. Tek bir çağrıda bunu gözden kaçırırsanız, hata tamamen başka bir yerde, hiçbir zaman geçerli olmamış verilerle ilgili kafa karıştırıcı bir hata olarak ortaya çıkar. Axios ise varsayılan olarak 2xx dışındaki kodları reddeder. Her iki yaklaşım da savunulabilir; ancak sadece biri her bir çağrıda disiplin gerektirir ve disiplin, teslim tarihi baskısı altındaki kod tabanlarının koruyabildiği bir özellik değildir.
Geri kalan her şey, ne geliştirdiğinize bağlıdır. Tarayıcıda, fetch yerleşik ve ücretsizdir ve basit istek kalıpları için şablon kodu çok basittir. Sunucuda ise paket boyutu artık önemli değildir ve fetch adresinde eksik olan özellikler — zaman aşımları, ara alıcılar, yeniden deneme, proxy yapılandırması — tam da sunucu kodunun ihtiyaç duyduğu şeylerdir, bu nedenle denge diğer tarafa kayar.
Uygulamaya değer bir test: fetch için bir sarmalayıcı yazdıysanız ve bu sarmalayıcı şu anda yaklaşık otuz satırdan fazlaysa, küçük bir HTTP kütüphanesini sürdürüyorsunuz demektir. Bu, kasıtlı olarak yapılmış meşru bir seçimdir; ancak kazara yapılmışsa kötü bir seçimdir.
Proxy'lere gelince — ki bu, insanların bir öğleden sonrasını boşa harcadıkları kısımdır: Node'daki yerel fetch, standart proxy ortam değişkenlerini yok sayar. HTTPS_PROXY ayarını yapmak hiçbir işe yaramaz; istek doğrudan gider ve herhangi bir hata oluşmaz. Bir undici ProxyAgent dağıtıcı sağlayın ya da Axios'un proxy seçeneğini kullanın — ve varsayımda bulunmak yerine, adres bildiren bir uç noktaya karşı doğrulama yapın.
Proxy satıyoruz ve çoğu sunucu tarafı isteği için proxyye gerek yoktur. Proxyye ihtiyaç duyduğunuz durumlarda, hangi istemciyi kullandığınızı bilmek hata ayıklamanın ilk adımıdır, son adımı değil.
