Axios vs. Fetch

Es gibt zwei Möglichkeiten, eine HTTP-Anfrage in JavaScript zu stellen – darüber wird endlos diskutiert, wobei sich die Debatte meist um die unwichtigsten Aspekte dreht.

Bundle-Größe, Eleganz der Syntax, die Frage, ob eine Abhängigkeit gerechtfertigt ist – das sind Geschmackssachen, und vernünftige Menschen kommen zu unterschiedlichen Schlussfolgerungen. Ein Unterschied ist jedoch keine Frage der Präferenz, sondern führt zu echten Fehlern im Produktionscode: fetch lehnt sein Promise nicht ab, wenn der Server einen Fehlerstatus zurückgibt. Ein 404-Fehler wird aufgelöst. Ein 500-Fehler wird aufgelöst. Dein .catch() wird nie ausgeführt, und der Code läuft weiter, als ob alles funktioniert hätte.

Das ist dokumentiertes Verhalten und keine Eigenart, und genau das muss man vor allem anderen verstehen.

Wir sind Geonode und verkaufen Proxys, daher hier ein themenbezogener Hinweis: Es gibt einen echten und unzureichend dokumentierten Unterschied zwischen diesen beiden in Bezug auf die Proxy-Unterstützung in Node, der viele Nutzer regelmäßig überrascht. Native „fetch“ in Node erkennt die standardmäßigen Proxy-Umgebungsvariablen nicht, was fast jeden überrascht, der davon ausgeht, dass es sich wie „curl“ verhält. Dazu gibt es einen eigenen Abschnitt, und wenn Sie Anfragen nicht über einen Proxy leiten, können Sie diesen Abschnitt komplett überspringen – was für die meisten Nutzer der Fall sein dürfte.

Eine kleine organisatorische Anmerkung, da sie alle betrifft, die älteren Links folgen: Die Dokumentation von Axios wurde verschoben. axios-http.com leitet nun zu axios.rest weiter. Lesezeichen und Stack-Overflow-Antworten, die auf die alte Domain verweisen, funktionieren weiterhin über die Weiterleitung, aber die kanonische Adresse hat sich geändert.

Alle folgenden Angaben zum Verhalten stammen von MDN und der Axios-eigenen Dokumentation und nicht aus der Erinnerung einzelner Personen.

Der Unterschied, der echte Fehler verursacht

Fangen Sie hier an, denn dies ist der einzige Unterschied, bei dem es nicht um Geschmack geht.

Was MDN dazu sagt

Direkt aus der Dokumentation:

„Ein ``fetch()`

-Promise wird nur abgelehnt, wenn die Anfrage fehlschlägt, beispielsweise aufgrund einer fehlerhaften Anfrage-URL oder eines Netzwerkfehlers. Ein ``fetch()

-Promise wird *nicht* abgelehnt, wenn der Server mit HTTP-Statuscodes antwortet, die auf Fehler hinweisen (z. B. 404`

, 504

usw.). Stattdessen muss ein ``then()`

-Handler die Eigenschaften ``Response.ok

und/oder ``Response.status

` überprüfen.“

Die Hervorhebung von nicht stammt von MDN selbst.

Was das in der Praxis bedeutet

// 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
}

Der Server hat einen 404-Fehler mit einem Fehlertext zurückgegeben. fetch

wurde problemlos aufgelöst. res.json()

hat das Fehlerobjekt geparst. showUser

hat etwas empfangen, das kein Benutzer ist, und der Fehler tritt später an anderer Stelle als verwirrender Fehler bezüglich einer undefinierten Eigenschaft zutage.

Die korrekte Version:

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);
}

Drei zusätzliche Zeilen, und diese sind bei jeder einzelnen Anfrage, die Sie schreiben, erforderlich.

Wie sich Axios verhält

Axios lehnt Statuscodes außerhalb des 2xx-Bereichs standardmäßig ab. Der entsprechende Code benötigt keine Statusprüfung:

try {
  const { data } = await axios.get('/api/user/999');
  showUser(data);
} catch (err) {
  showError(err);          // runs on a 404
}

Welches Verhalten ist korrekt?

Beides ist vertretbar, und die Meinungsverschiedenheit ist philosophischer Natur.

fetch

vertritt den Standpunkt, dass die Übertragung erfolgreich war – der Server wurde erreicht, er hat geantwortet, die Antwort ist unversehrt angekommen. Ein 404 ist eine gültige Antwort auf eine Anfrage, kein Fehlschlag bei der Anfrage selbst. Ein Ablehnen würde einen Transportfehler mit der Anwendungssemantik vermischen. Dies ist übrigens genau auch die Position von curl, wo ein 404 ebenfalls einen Exit-Code von Null erzeugt.

Axios vertritt die Ansicht, dass die meisten Aufrufer einen 4xx- oder 5xx-Fehler als Fehlschlag betrachten, weshalb er sich auch wie ein solcher verhalten sollte.

In der Praxis ist das Modell von „fetch

“ zwar korrekter, aber auch fehleranfälliger, da es bei jedem Aufruf Disziplin erfordert und keine Warnung erfolgt, wenn diese Disziplin nachlässt.

Was Fetch ist und was es kostet

Der Standard mit seinen Vorteilen und seinen Einschränkungen.

Die Vorteile

Es ist fest integriert. Keine Abhängigkeiten, keine Installation, keine Bundle-Kosten, keine Lieferkette, die geprüft werden muss. In Browsern und in modernem Node ist es einfach vorhanden.

Es ist ein Standard. Er wurde festgelegt und wird nicht von einem Projekt gepflegt, das möglicherweise seine Ausrichtung ändert, aufgegeben wird oder nach eigenem Zeitplan eine kompatibilitätsbrechende Änderung einführt.

Es ist die Grundlage. Viele übergeordnete Bibliotheken sind Wrapper darum herum, sodass das Verständnis von „fetch“ bedeutet, zu verstehen, was diese Bibliotheken tun.

Es kommt gut mit Streaming zurecht. Response.body ist ein lesbarer Stream, was die schrittweise Verarbeitung großer Antworten auf natürliche Weise ermöglicht.

Was es nicht leistet

Dies sind die Lücken, die Sie selbst füllen müssen, und ihre Anzahl ist das eigentliche Argument für Axios.

Kein automatisches JSON. Man ruft .json() auf, was ein weiteres await und eine weitere Stelle ist, an der es zu einem Fehler kommen kann, wenn die Antwort kein JSON ist – beispielsweise eine HTML-Fehlerseite, was genau das ist, was man von einem falsch konfigurierten Server erhält.

Keine Statusablehnung. Wurde oben bereits behandelt.

Standardmäßig kein Timeout. Ein fetch kann sich unbegrenzt aufhängen. AbortSignal.timeout() bietet in modernen Umgebungen zwar eine solche Funktion, diese muss jedoch aktiviert werden und wird leicht vergessen – was gerade in den Situationen am wichtigsten ist, in denen ein Hängenbleiben am schlimmsten ist.

Keine Interceptors. Es gibt keine Möglichkeit, ein Authentifizierungstoken, eine Korrelations-ID oder eine Protokollierung zentral anzuhängen. Entweder wird dies bei jedem Aufruf wiederholt oder man schreibt einen Wrapper – und genau beim Schreiben eines Wrappers bauen Entwickler versehentlich ihr eigenes, schlechteres Axios auf.

Kein Upload-Fortschritt. Der Download-Fortschritt ist über den Response-Stream möglich; der Upload-Fortschritt ist nicht ohne Weiteres realisierbar.

Keine automatische Serialisierung des Request-Bodys. Man ruft JSON.stringify auf und legt den Content-Type jedes Mal selbst fest.

Keine Proxy-Konfiguration in Node. Dazu gibt es weiter unten einen eigenen Abschnitt.

Die ehrliche Zusammenfassung

fetch ist eine gut konzipierte Low-Level-Primitive. Ihre Auslassungen sind bewusst gewählt – ein Standard sollte minimalistisch und wertfrei sein.

Die Frage ist nicht, ob es gut ist. Die Frage ist, ob Sie die fehlende Ebene selbst implementieren möchten und ob die von Ihnen implementierte Version besser sein wird als eine, die von einem Projekt mit einer großen Nutzerbasis gepflegt wird, die deren Randfälle aufdeckt.

Was Axios Ihnen bietet

Die Funktionsliste aus der eigenen Dokumentation spricht für sich.

Promise-basierter HTTP-Client mit einer umgebungsübergreifend einheitlichen Schnittstelle, der separate Browser- und Node-Bundles bereitstellt.

Interceptors für Anfragen und Antworten – das ist die wertvollste Funktion und zugleich diejenige, die sich am schwersten sauber nachzubilden lässt. Fügen Sie einen Authentifizierungs-Header einmal hinzu, behandeln Sie den 401-Refresh einmal, fügen Sie die Protokollierung einmal hinzu – und jede Anfrage in der Anwendung übernimmt diese Einstellungen.

Automatische JSON-Verarbeitung in beide Richtungen. Anfragetexte werden serialisiert und der Inhaltstyp festgelegt; Antworten werden in „response.data“ geparst.

Fehlerbehandlung mit Ablehnung bei Statuscodes, die nicht im 2xx-Bereich liegen.

Timeout-Konfiguration, die in der Dokumentation als Schutz vor unbegrenztem Hängenbleiben von Anfragen beschrieben wird. Ein Konfigurationswert anstelle eines Abbruch-Controllers pro Aufruf.

Abbruch laufender Anfragen.

Fortschrittsverfolgung sowohl für Uploads als auch für Downloads, was „fetch“ nicht ohne Weiteres bietet.

XSRF-Schutz integriert.

Datei-Posting und Multipart-Formulardaten werden für Sie verarbeitet.

Ratenbegrenzung und Drosselung von Anfragen.

Instanzen mit Standardwerten, sodass ein konfigurierter Client mit Basis-URL, Headern und Timeout einmal erstellt und überall importiert werden kann.

Die Kosten

Eine Abhängigkeit. Etwas, das installiert, auf dem neuesten Stand gehalten und geprüft werden muss. In einer sicherheitsbewussten Umgebung sind das echte Kosten und keine theoretischen.

Bundle-Größe. Für ein kleines Frontend von Bedeutung, für eine große Anwendung oder serverseitige Komponenten vernachlässigbar.

Eine weitere Abstraktion, die es zu erlernen gilt, und zwar eine, die sich gelegentlich auf überraschende Weise anders verhält als die zugrunde liegende Plattform.

Die faire Einordnung

Axios entspricht in etwa dem, was die meisten Leute letztendlich auf der Grundlage von fetch entwickeln, wenn sie diese Funktionen benötigen – nur dass es bereits geschrieben, bereits debuggt ist und bereits Fälle abdeckt, an die Sie noch gar nicht gedacht haben.

Wenn Sie nichts davon benötigen, ist es eine unnötige Abhängigkeit.

Im Vergleich

	fetch	Axios
Installation	Integriert	npm install
Abbruch bei 404/500	Nein	Ja
JSON-Parsing	Manuell .json()	Automatisch
Serialisierung des Request-Bodys	Manuell	Automatisch
Timeout	AbortSignal.timeout()	Konfigurationsoption
Interceptors	Nein	Ja
Upload-Fortschritt	Nicht ohne Weiteres möglich	Ja
Download-Fortschritt	Über Antwort-Stream	Ja
Abbruch	AbortController	Integriert
XSRF-Schutz	Manuell	Integriert
Instanzen mit Standardwerten	Nein	Ja
Proxy-Konfiguration in Node	Nein	Ja
Streaming	Hervorragend	Eher eingeschränkt
Bundle-Kosten	Null	Gering, aber ungleich Null

Dieselbe Anfrage, auf zwei Arten

// 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 }
);

Beide sind korrekt. Die „fetch“-Version umfasst elf Zeilen gegenüber fünf bei Axios, und der Unterschied besteht ausschließlich aus Dingen, die man bei jedem Aufruf beachten muss, anstatt sie einmalig zu konfigurieren.

Die beiden entscheidenden Zeilen

Ablehnung bei 404/500 und Proxy-Konfiguration in Node sind die einzigen Zeilen, bei denen das eine Tool nicht ohne Weiteres das leisten kann, was das andere tut. Der Rest ist Standardcode, und Standardcode ist eher ein Aufwand als ein unüberwindbares Hindernis.

Die „Boilerplate“-Steuer

Der eigentliche Vergleich findet nicht zwischen einem Aufruf von „fetch

“ und einem Aufruf von „axios

“ statt. Er erfolgt zwischen zwei Codebasen, die jeweils eine dieser Funktionen verwenden.

Was letztendlich jeder schreibt

Nachdem man die Statusprüfung, das Timeout und das Parsen von JSON zum dritten oder vierten Mal wiederholt hat, schreibt man Folgendes:

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();
}

Das ist ein vernünftiger und recht guter Wrapper. Es ist aber auch, unverkennbar, ein kleines Axios.

Was der Wrapper nicht bewältigt, bis es jemand bemerkt

Wiederholungsversuche mit Backoff. Token-Aktualisierung bei 401 ohne Request-Storm, wenn mehrere Aufrufe gleichzeitig fehlschlagen. Anfragen, die HTML statt JSON zurückgeben. 204-Antworten ohne Body. Abbruch, der durch verschachtelte Aufrufe weitergegeben wird. Upload-Fortschritt. Andere Inhaltstypen als JSON. Korrelations-IDs zur Nachverfolgung.

Jedes davon ist eine kleine Ergänzung. Zusammengenommen bilden sie eine Bibliothek, und die von dir geschriebene Version wird weniger getestet sein als die, die bereits Tausende von Menschen nutzen.

Wann es richtig ist, es selbst zu schreiben

Wenn du nur sehr wenig davon benötigst. Eine Handvoll GET-Anfragen an eine API. Der oben genannte Wrapper umfasst dreißig Zeilen und gehört vollständig dir.

Wenn die Bundle-Größe wirklich eine Rolle spielt. Eine leistungskritische Seite, bei der jedes Kilobyte zählt.

Wenn Abhängigkeiten aufwendig sind. Umgebungen, in denen jedes Paket einer Überprüfung bedarf.

Wenn du die Plattform verstehen willst. Ein berechtigter Grund, und das Verständnis lässt sich übertragen.

Wann es nicht sinnvoll ist

Wenn du bereits bei der dritten Iteration des Wrappers bist, wenn verschiedene Teile der Codebasis unterschiedliche Wrapper haben oder wenn du eine Wiederholungslogik hinzufügst. An diesem Punkt wartest du eine Bibliothek als Nebenprojekt, und die Abhängigkeit, die du vermieden hast, ist kostengünstiger als die, die du selbst erstellt hast.

Bundle-Größe und die Frage nach den Knoten

Die beiden kontextbezogenen Faktoren, die die Antwort beeinflussen.

Im Browser

Axios erhöht das Gewicht Ihres Bundles. Ob das eine Rolle spielt, hängt ganz davon ab, was Sie entwickeln.

Eine Landingpage oder ein Widget, bei denen die Ladezeit das Produkt ist – verwenden Sie fetch. Jedes Kilobyte zählt, und die Anfragemuster sind in der Regel so einfach, dass der Boilerplate-Code trivial ist.

Eine große Anwendung, die bereits ein Framework und eine Komponentenbibliothek enthält – die Grenzkosten sind vernachlässigbar, und die Unterstützung für Interceptors ist deutlich mehr wert als die Bytes.

Ehrlich gesagt ist die Bundle-Größe das Argument, auf das Leute zurückgreifen, wenn sie einen technischen Grund für eine ästhetische Präferenz suchen. Sie ist real, spielt aber weitaus seltener eine entscheidende Rolle, als oft behauptet wird.

In Node

Eine völlig andere Rechnung. Die Bundle-Größe ist auf einem Server irrelevant, sodass das Hauptargument gegen Axios hinfällig wird.

Native „fetch“ ist in modernen Node-Versionen verfügbar und funktioniert gut. Aber serverseitiger Code benötigt in der Regel genau die Dinge, die „fetch“ auslässt: Timeouts für alles, Wiederholungsversuche mit Backoff, zentralisierte Authentifizierungsabwicklung, strukturierte Protokollierung ausgehender Aufrufe und – wie im nächsten Abschnitt behandelt – Proxy-Konfiguration.

Daher neigt sich die Waage auf dem Server stärker zugunsten von Axios als im Browser, was genau das Gegenteil dessen ist, wie das Argument normalerweise vorgebracht wird.

Der Kompromiss, den niemand erwähnt

Man kann beides verwenden. „fetch“ für einfache Aufrufe, Axios dort, wo man die Funktionen benötigt. Nichts verbietet dies, und das Argument der Konsistenz ist schwächer, als es klingt.

Was wirklich Probleme verursacht, sind drei verschiedene selbst entwickelte Wrapper in einer Codebasis, die Fehler jeweils etwas unterschiedlich behandeln. Das ist schlimmer, als wenn eine der beiden Bibliotheken konsequent verwendet würde, und genau dort landen überraschend viele Projekte.

Proxys in beiden Fällen

Unser Fachgebiet – und die Ursache für einen wahrhaft verwirrenden Nachmittag für viele Entwickler.

Die Kurzfassung

Der native „fetch“ in Node liest die standardmäßigen Proxy-Umgebungsvariablen nicht. Das Setzen von „HTTP_PROXY“ und „HTTPS_PROXY“ hat keinerlei Auswirkung – anders als bei „curl“, anders als bei den meisten HTTP-Bibliotheken und anders als fast jeder erwartet.

Das globale „fetch“ von Node basiert auf „undici“, und für das Routing über einen Proxy muss ein Dispatcher explizit angegeben werden:

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');

Oder pro Anfrage durch Übergabe der Option „dispatcher“.

Axios in Node

Axios verfügt über die Konfigurationsoption „proxy“:

const res = await axios.get('https://example.com', {
  proxy: {
    protocol: 'http',
    host: 'proxy.example.com',
    port: 8080,
    auth: { username: 'user', password: 'pass' }
  }
});

Für SOCKS-Proxys oder zur feineren Steuerung ist der übliche Ansatz eine Agent-Bibliothek, die als „httpAgent“ und „httpsAgent“ übergeben wird.

Im Browser geht beides nicht

Das ist erwähnenswert, weil es Zeit spart. JavaScript im Browser kann keinen Proxy einrichten. Der Browser verwendet die vom System oder einer Erweiterung konfigurierten Einstellungen, und keine Bibliothek kann dies ändern. Die Option „proxy“ von Axios ist eine Node-Funktion.

Wenn Sie aus browserbasiertem Code heraus Proxy-Anfragen benötigen, muss die Anfrage über einen Server laufen, den Sie kontrollieren.

Der Hinweis beim Debuggen

Wenn ein Proxy in Node „nicht funktioniert“, prüfe zunächst, welcher Client die Anfrage stellt, bevor du irgendetwas anderes überprüfst. Code, der mit Axios funktioniert und mit fetch fehlschlägt – oder umgekehrt –, weist fast immer dieses Problem auf, und es bleibt unsichtbar, da in beiden Fällen keine Fehlermeldung ausgegeben wird. Die Anfrage wird einfach direkt weitergeleitet.

Überprüfen Sie dies, indem Sie über Ihren konfigurierten Client einen Endpunkt zur Adressausgabe anfragen und sich vergewissern, dass die zurückgegebene Adresse die des Proxys ist.

Und der Teil, der unseren eigenen Interessen zuwiderläuft

Die meisten serverseitigen HTTP-Aufrufe benötigen überhaupt keinen Proxy. Der Aufruf einer API, für die Sie über Anmeldedaten verfügen, von einem Server aus, der Zugriff darauf hat, erfordert keine zusätzlichen Maßnahmen – ein Proxy verursacht Latenz, eine Fehlerquelle und Kosten. Proxys bewähren sich bei der geografischen Überprüfung und bei der Abfrage großer Datenmengen, bei denen Ratenbeschränkungen pro Adresse greifen. Abgesehen davon ist der einfache Client die bessere Wahl.

Welche Variante soll man wählen?

Eher eine Entscheidungshilfe als eine pauschale Empfehlung.

Verwenden Sie „fetch“, wenn

die Größe des Bundles wirklich entscheidend ist. Landingpages, Widgets, eingebettete Skripte.

Ihre Anfragen einfach sind. Ein paar GET-Anfragen, minimale Fehlerbehandlung, keine gemeinsame Authentifizierung.

Sie können keine Abhängigkeiten hinzufügen, oder jedes Paket muss geprüft werden.

Sie arbeiten mit Streams. Das Streaming-Modell von „fetch“ ist besser, und das ist ein echter technischer Vorteil und keine bloße Präferenz.

Sie möchten die Plattform kennenlernen. Das Wissen lässt sich übertragen; Axios-spezifisches Wissen hingegen nicht.

Verwenden Sie Axios, wenn

Sie Interceptors benötigen. Zentralisierte Authentifizierung, Token-Aktualisierung, Protokollierung, Korrelations-IDs. Dies ist der wichtigste Einzelgrund, und es gibt kein klares Äquivalent bei „fetch“.

Sie auf dem Server arbeiten. Die Bundle-Größe spielt keine Rolle, und die fehlenden Funktionen sind genau das, was Servercode benötigt.

Sie benötigen einen Upload-Fortschrittsanzeige, was mit fetch nicht einfach zu bewerkstelligen ist.

Sie stellen viele unterschiedliche Anfragen über eine große Codebasis hinweg und wünschen sich ein konsistentes Verhalten, ohne einen Wrapper pflegen zu müssen.

Sie benötigen eine Proxy-Konfiguration und würden lieber eine dokumentierte Option nutzen, als einen Dispatcher zusammenzustellen.

Egal, wofür Sie sich entscheiden

Legen Sie immer ein Timeout fest. AbortSignal.timeout() oder die Option „timeout“ von Axios. Eine Anfrage ohne Timeout kann sich endlos hinziehen, und dies ist der häufigste Zuverlässigkeitsfehler in JavaScript-HTTP-Code.

Überprüfen Sie den Status immer mit „fetch“. Bei jedem Aufruf, ohne Ausnahme. „res.ok“ besteht aus zwei Wörtern, und das Fehlen dieser beiden Wörter ist der Fehler, mit dem dieser Artikel begann.

Zentralisieren Sie es. Ein Wrapper oder eine konfigurierte Axios-Instanz. Drei inkonsistente Ansätze in einer Codebasis sind schlimmer als jede der beiden Bibliotheken, und das ist das Ergebnis, für das sich niemand bewusst entscheidet.

Häufig gestellte Fragen

Was ist der Hauptunterschied zwischen Axios und fetch?

Fehlerbehandlung. Laut MDN wird ein „fetch“-Promise „nicht abgelehnt, wenn der Server mit HTTP-Statuscodes antwortet, die auf Fehler hinweisen“ – Sie müssen response.ok selbst überprüfen. Axios lehnt bei Statuswerten außerhalb des 2xx-Bereichs ab. Alles andere ist Komfort: Axios bietet Interceptors, automatische JSON-Konvertierung, Timeouts, Fortschrittsanzeige und Proxy-Konfiguration.

Wird Axios noch benötigt, jetzt wo fetch integriert ist?

Das hängt davon ab, was du benötigst. Für einfache Anfragen: nein. Für Interceptors, Upload-Fortschrittsanzeige, instanzspezifische Standardeinstellungen oder Node-Proxy-Konfiguration bietet Axios nach wie vor Funktionen, die fetch nicht bietet, und diese selbst zu schreiben bedeutet, eine kleine Bibliothek zu pflegen.

Warum löst fetch bei einem 404-Fehler keinen Ausnahmetyp aus?

Weil die Übertragung erfolgreich war – der Server wurde erreicht und hat geantwortet. fetch behandelt einen 404-Fehler als gültige Antwort und nicht als fehlgeschlagene Anfrage und lehnt nur bei Netzwerkfehlern oder einer fehlerhaften URL ab. Überprüfen Sie bei jedem Aufruf response.ok.

Was ist schneller, Axios oder fetch?

Bei einer einzelnen Anfrage ist der Unterschied vernachlässigbar; beide sind vom Netzwerk abhängig. Axios verursacht einen geringen zusätzlichen Verarbeitungsaufwand und im Browser einen geringen Downloadaufwand für die Bibliothek selbst.

Wie lege ich mit fetch ein Timeout fest?

AbortSignal.timeout(5000) In modernen Umgebungen wird dies als Option „signal“ übergeben, oder über „AbortController“ mit einem eigenen Timer. Es gibt kein Standard-Timeout, daher kann eine Anfrage ohne Timeout unbegrenzt hängen bleiben.

Funktioniert „fetch“ mit Proxys in Node?

Nicht über die üblichen Umgebungsvariablen. Das globale „fetch“ von Node basiert auf „undici“ und liest weder „HTTP_PROXY“ noch „HTTPS_PROXY“. Sie müssen einen „ProxyAgent“-Dispatcher angeben, entweder global mit „setGlobalDispatcher“ oder pro Anfrage. Axios verfügt stattdessen über die Konfigurationsoption „proxy“.

Kann ich im Browser einen Proxy mit „fetch“ verwenden?

Nein. JavaScript im Browser kann keinen Proxy konfigurieren – der Browser verwendet die System- oder Erweiterungs-Einstellungen. Die Proxy-Option einer Bibliothek ist eine reine Node-Funktion. Proxy-Anfragen aus dem Browser müssen über einen Server laufen, den Sie kontrollieren.

Sollte ich in einem Projekt sowohl Axios als auch fetch verwenden?

Das ist an sich kein Problem. Was echte Schwierigkeiten verursacht, sind mehrere inkonsistente, selbst entwickelte Wrapper mit unterschiedlichem Fehlerverhalten. Konsistenz bei der Behandlung von Fehlern ist wichtiger als die Frage, welche Bibliothek die Anfrage erzeugt hat.

Fazit

Ein Unterschied ist inhaltlicher Natur, der Rest ist Geschmackssache.

** „fetch“ lehnt HTTP-Fehler nicht ab.** MDN stellt dies ausdrücklich klar: Ein 404- oder 504-Fehler wird aufgelöst, und Sie müssen selbst prüfen, ob response.ok oder response.status gültig ist. Wenn man das bei einem Aufruf übersieht, tritt der Fehler an einer ganz anderen Stelle zutage – als verwirrender Fehler bezüglich Daten, die nie gültig waren. Axios lehnt standardmäßig alle Nicht-2xx-Codes ab. Beide Positionen sind vertretbar; nur eine erfordert Disziplin bei jedem einzelnen Aufruf, und Disziplin ist keine Eigenschaft, die Codebasen unter Termindruck beibehalten.

Alles andere hängt davon ab, was Sie entwickeln. Im Browser ist fetch integriert und kostenlos, und für einfache Anfragemuster ist der Boilerplate-Code trivial. Auf dem Server spielt die Bundle-Größe keine Rolle mehr, und die Funktionen, die fetch auslässt – Timeouts, Interceptors, Wiederholungsversuche, Proxy-Konfiguration – sind genau das, was Servercode benötigt, sodass sich die Waage in die andere Richtung neigt.

Der Test, den es sich lohnt durchzuführen: Wenn du einen Wrapper um fetch geschrieben hast und dieser nun mehr als etwa dreißig Zeilen umfasst, wartest du eine kleine HTTP-Bibliothek. Das ist eine legitime, bewusst getroffene Entscheidung – oder eine schlechte, die aus Versehen getroffen wurde.

Was Proxys angeht – und das ist der Teil, an dem die Leute einen ganzen Nachmittag verlieren: Das native fetch in Node ignoriert die standardmäßigen Proxy-Umgebungsvariablen. Das Setzen von HTTPS_PROXY bewirkt nichts, die Anfrage geht direkt durch, und es wird kein Fehler gemeldet. Stellen Sie einen undici-ProxyAgent-Dispatcher bereit oder nutzen Sie die Option proxy von Axios – und überprüfen Sie dies anhand eines Endpunkts, der die Adresse zurückgibt, anstatt einfach davon auszugehen.

Wir verkaufen Proxys, und die meisten serverseitigen Anfragen benötigen keinen. Wenn Sie doch einen benötigen, ist das Wissen darum, welchen Client Sie verwenden, der erste Schritt bei der Fehlersuche – nicht der letzte.