Frage zu fetch "init" Object

[Tom]

Hallo...

Mich verunsichert die ambivalente Dokumentation der Notwendigkeit des init-Objects (wie es auf MDN genannt wird) der fetch-API ein wenig...

Inwieweit benötige ich selbiges, bzw. welche Inhalte sollte es auf jeden Fall aufweisen?

Oder anders ausgedrückt -

Was spricht gegen ein simples

fetch("testingFetch_1.0.php")
  .then(response => response.text())
  .then(data => DOMElement.innerHTML = data)
  .catch(err => console.log('UIJE: ', err));

Ist die Sache bei einem POST Request genauer zu formulieren um vielleicht Schabernack auf dem Server / in der Datenbank vorzubeugen?

Sehe offensichtlich den Wald vor lauter Bäumen nicht,

Dank euch, Tom

[Rolf B]

Hallo Tom,

das init-Objekt enthält eine ganze Masse an Optionen. Wenn Du mit deren Defaults auskommst, spricht nichts dagegen, auf seinen Einsatz zu verzichten.

Einen POST Request bekommst Du ohne init aber nicht hin, weil

1. der Default für die method-Eigenschaft 'GET' ist. Das steht zwar nicht bei MDN, aber - etwas verteilt - in der Spezifikation
2. POST einen Body braucht und Du den ebenfalls im init-Objekt einträgst

DOMElement.innerHTML = data

Ob das korrekt ist, hängt vom Anwendungsfall ab. Wenn Dir Dein Server ein HTML Fragment liefert, ja, dann musst Du das tun. Wenn er Dir Text liefert und Du kein HTML erwartest, dann solltest Du das nicht tun, sondern data an die textContent-Eigenschaft zuweisen. Oder einen Textnode erzeugen und den als Child-Element an das DOMElement anhängen, es gibt viele Möglichkeiten und jede kann abhängig von den Umständen richtig sein

Bei einem POST Request gibst Du ja einen Body mit, und da ist es eigentlich Sache des Servers, Schabernack abzuwehren. Unser Wiki hat da leider eine Riesenbaustelle. Hier bei MDN sind ein paar Beispiele.

Rolf

[Tom]

Oki Danke 🙃

...machte mich nervös, bei einer API eine gesamte Kette an Konfigurationsoptionen nonchalant einfach wegzulassen

[dedlfix]

Tach!

...machte mich nervös, bei einer API eine gesamte Kette an Konfigurationsoptionen nonchalant einfach wegzulassen

Die API muss doch beschreiben, was sie konkret alles benötigt. Vor allem die Parameters method und headers sind dafür ausschlaggebend. Andere Parameter betreffen das Verhalten des Browsers. Bei denen musst du selbst schauen, was du da für ein Verhalten benötigst.

dedlfix.

[dedlfix]

Tach!

Einen POST Request bekommst Du ohne init aber nicht hin, weil

1. der Default für die method-Eigenschaft 'GET' ist. Das steht zwar nicht bei MDN, aber - etwas verteilt - in der Spezifikation

Der verlinkte Absatz im OP verweist zwar auf die fetch()-Seite der MDN für genauere Beschreibungen der Optionen, aber auf der sind die Default-Werte nicht benannt. Jedoch zählt das angegebene Beispiel die Optionen auf und hat den Default-Wert mit einem Sternchen versehen.

2. POST einen Body braucht und Du den ebenfalls im init-Objekt einträgst

Es gibt einige Server-Implementationen, die können mit mehreren Datenformaten umgehen. Zum Beispiel kann das .NET-Framework Daten in (mindestens) JSON und XML erkennen. Dazu muss aber der Client den Content-Type-Header korrekt gesetzt haben. Diese Angabe wirkt sich dann auf das Parsen der empfangenen Request-Daten im Body aus, als auch auf das Format der Response.

dedlfix.