Fast jede moderne Web-App muss Daten von einem Server holen oder zu ihm schicken: ein Produktkatalog, ein Login-Formular, ein Suchergebnis oder eine Wetteranzeige. Im Browser ist die Fetch API dafür heute das Standardwerkzeug. Sie ersetzt das umständliche XMLHttpRequest der Anfangsjahre durch eine klare, auf Promises aufbauende Schnittstelle. In diesem Ratgeber sehen wir uns an, wie du mit fetch() Daten lädst und sendest, wie du JSON verarbeitest, Header setzt, Fehler sauber behandelst und Anfragen wieder abbrichst.
Was die Fetch API ist und wie sie funktioniert
fetch() ist eine global verfügbare Funktion in jedem aktuellen Browser. Sie nimmt eine URL entgegen und gibt ein Promise zurück. Sobald der Server antwortet, wird dieses Promise mit einem Response-Objekt erfüllt. Wichtig ist die Reihenfolge: Das Promise löst sich auf, sobald die Antwort-Header eingetroffen sind, nicht erst wenn der gesamte Inhalt geladen ist. Den eigentlichen Inhalt holst du dir in einem zweiten Schritt, zum Beispiel über response.json() oder response.text().
Ein einfacher GET-Aufruf mit async/await sieht so aus:
const response = await fetch('/api/produkte');startet die Anfrage und wartet auf die Header.const daten = await response.json();liest den Antwort-Body und wandelt ihn in ein JavaScript-Objekt um.- Beide Schritte sind asynchron, weil weder die Netzwerkantwort noch das Parsen sofort fertig sind.
Der Aufruf von response.json() gibt selbst wieder ein Promise zurück. Das ist leicht zu übersehen und eine häufige Fehlerquelle bei Einsteigern, die das await vergessen und sich dann über ein "Promise"-Objekt statt der erwarteten Daten wundern.
Warum du immer response.ok prüfen solltest
Eine Eigenheit der Fetch API überrascht viele: Ein HTTP-Fehler wie 404 Not Found oder 500 Internal Server Error führt nicht dazu, dass das Promise abgelehnt wird. Aus Sicht von fetch() war die Anfrage erfolgreich, schließlich ist eine Antwort angekommen. Das Promise schlägt nur fehl, wenn gar keine Verbindung zustande kommt, etwa bei Netzwerkausfall oder einer geblockten Anfrage.
Deshalb musst du den Status selbst auswerten. Das Response-Objekt bietet dafür zwei nützliche Felder:
response.okisttrue, wenn der Statuscode im Bereich 200 bis 299 liegt.response.statusenthält den konkreten Code, etwa 404 oder 503.
Ein robustes Muster prüft also zuerst response.ok und wirft bei Bedarf einen eigenen Fehler, bevor der Body gelesen wird. So fängst du Serverfehler in deinem catch-Block genauso ab wie echte Netzwerkprobleme.
Daten mit POST senden
Zum Abrufen reicht oft die URL allein. Wenn du Daten an den Server schickst, etwa beim Speichern eines Formulars, übergibst du fetch() ein zweites Argument: ein Konfigurationsobjekt. Drei Felder sind dabei zentral:
- method: die HTTP-Methode, zum Beispiel
'POST'. - headers: ein Objekt mit den Anfrage-Headern. Beim Senden von JSON gehört hier
'Content-Type': 'application/json'hinein. - body: der eigentliche Inhalt. JSON musst du vorher mit
JSON.stringify(objekt)in einen String umwandeln, weil der Body eine Zeichenkette erwartet.
Ein typischer POST-Aufruf lädt also ein JavaScript-Objekt, serialisiert es zu JSON und teilt dem Server über den Header mit, in welchem Format die Daten vorliegen. Vergisst du den Content-Type, kann der Server die Daten oft nicht korrekt einlesen. Für Datei-Uploads oder klassische Formulardaten nutzt du statt eines JSON-Strings ein FormData-Objekt; den Content-Type setzt der Browser dann automatisch passend.
HTTP-Methoden im Überblick
Welche Methode du wählst, hängt davon ab, was du mit der Ressource vorhast. Die folgende Übersicht zeigt die gebräuchlichsten HTTP-Methoden, ihren typischen Einsatzzweck und ob ein Body üblich ist.
| Methode | Typischer Einsatzzweck | Body üblich? |
|---|---|---|
| GET | Daten abrufen, ohne etwas zu verändern | Nein |
| POST | Neue Ressource anlegen oder Aktion auslösen | Ja |
| PUT | Bestehende Ressource vollständig ersetzen | Ja |
| PATCH | Bestehende Ressource teilweise aktualisieren | Ja |
| DELETE | Ressource löschen | Selten |
GET-Anfragen sollten keine Nebenwirkungen haben, sich also wiederholen lassen, ohne den Serverzustand zu ändern. POST gilt dagegen als nicht idempotent: Zweimal abgeschickt, kann es zwei Datensätze anlegen. PUT und DELETE sind wiederum so gedacht, dass mehrere identische Aufrufe denselben Endzustand erzeugen.
Header setzen und auslesen
Header transportieren Zusatzinformationen über eine Anfrage oder Antwort. Beim Senden setzt du sie über das headers-Feld. Häufige Beispiele sind:
Content-Type: in welchem Format der Body vorliegt, etwaapplication/json.Authorization: ein Token zur Authentifizierung, oft im FormatBearer ....Accept: in welchem Format du die Antwort bevorzugst.
Auf der Antwortseite liest du Header über response.headers.get('Content-Type') aus. Das ist praktisch, um vor dem Parsen zu prüfen, ob der Server überhaupt JSON zurückliefert oder vielleicht eine HTML-Fehlerseite. Beachte außerdem, dass Anfragen an andere Domains den CORS-Regeln des Browsers unterliegen: Der Zielserver muss das Lesen seiner Antwort per Header ausdrücklich erlauben.
Anfragen abbrechen mit AbortController
Langlaufende oder überflüssig gewordene Anfragen kannst du gezielt stoppen. Das ist zum Beispiel bei einer Live-Suche sinnvoll, bei der jede Tasteneingabe eine neue Anfrage auslöst und die vorherige nicht mehr gebraucht wird. Das Werkzeug dafür ist der AbortController:
- Du erzeugst einen Controller:
const controller = new AbortController(); - Du übergibst sein Signal an fetch:
fetch(url, { signal: controller.signal }). - Mit
controller.abort()brichst du die Anfrage ab. Das Promise wird dann mit einemAbortErrorabgelehnt.
Dasselbe Signal lässt sich auch mit einem Timeout kombinieren, um eine Anfrage nach einer festen Zeitspanne automatisch zu beenden. Im catch-Block solltest du den AbortError gesondert behandeln, denn ein bewusster Abbruch ist kein echter Fehler und sollte den Nutzer nicht mit einer Fehlermeldung behelligen.
Unterschied zu XMLHttpRequest und Bibliotheken
Vor der Fetch API war XMLHttpRequest (XHR) der einzige Weg, Daten ohne Seitenneuladen zu holen. XHR funktioniert über Ereignis-Callbacks und gilt als umständlich und schnell unübersichtlich. Bibliotheken wie axios entstanden unter anderem, um diese Lücke zu schließen. Heute deckt fetch() die meisten Anwendungsfälle nativ ab, ganz ohne zusätzliche Abhängigkeit. Bibliotheken können dennoch Komfort bieten, etwa automatisches JSON-Parsen, Interceptors oder eingebautes Werfen bei Fehlerstatus.
Für viele Projekte ist die native Fetch API die schlankere Wahl: kein zusätzlicher Code im Bundle, eine vom Browser gepflegte und sichere Schnittstelle und ein modernes Promise-Modell. Wer mehrere komplexe Abläufe orchestriert, kann sich eine kleine eigene Wrapper-Funktion schreiben, die response.ok prüft und JSON parst, und damit das Beste aus beiden Welten verbinden. Zum schnellen Ausprobieren von JSON-Strukturen oder zum Umwandeln von Datenformaten findest du auf kotsch.tech praktische Helfer.
Häufige Fragen
Warum erkennt fetch einen 404-Fehler nicht automatisch?
Weil fetch() jede empfangene Serverantwort als Erfolg wertet, unabhängig vom Statuscode. Das Promise schlägt nur bei echten Netzwerkproblemen fehl. Prüfe deshalb selbst response.ok und reagiere bei false mit einem eigenen Fehler.
Muss ich beim POST immer JSON.stringify verwenden?
Nur wenn du JSON sendest. Der Body erwartet einen String, deshalb wandelst du ein Objekt mit JSON.stringify() um. Schickst du Formulardaten oder Dateien, nutzt du stattdessen ein FormData-Objekt, das du direkt übergeben kannst.
Wie verarbeite ich die Antwort, wenn sie kein JSON ist?
Das Response-Objekt bietet mehrere Lesemethoden: response.text() für Text, response.blob() für Binärdaten wie Bilder und response.json() für JSON. Wähle die Methode passend zum Inhalt, den der Server zurückgibt.
Funktioniert die Fetch API in allen Browsern?
In allen aktuellen Browsern ist fetch() verfügbar. Nur sehr alte Browser kennen sie nicht. In modernen Node.js-Versionen steht fetch ebenfalls global zur Verfügung, sodass derselbe Code oft auf Server und Client läuft.
Wie setze ich ein Authentifizierungs-Token?
Über das headers-Feld der Anfrage, üblicherweise als Authorization: 'Bearer DEIN_TOKEN'. Achte darauf, sensible Tokens nicht im Quellcode der Webseite offenzulegen, da dieser für jeden einsehbar ist.
Wie verhindere ich, dass sich viele Anfragen überlagern?
Setze einen AbortController ein und brich die vorherige Anfrage ab, bevor du eine neue startest. So bleibt bei einer Live-Suche oder schnellen Wiederholungen immer nur die zuletzt gestartete Anfrage aktiv.
Mehr Anleitungen rund um Webentwicklung findest du in unseren News, nützliche kleine Helfer für den Alltag im Bereich Webtools, und einen Überblick über alle Angebote auf kotsch.tech.