The Fetch API provides a JavaScript interface for accessing and manipulating parts of the protocol, such as requests and responses. It also provides a global fetch() method that provides an easy, logical way to fetch resources asynchronously across the network.
This kind of functionality was previously achieved using XMLHttpRequest. Fetch provides a better alternative that can be easily used by other technologies such as Service Workers. Fetch also provides a single logical place to define other HTTP-related concepts such as CORS and extensions to HTTP.
The fetch specification differs from jQuery.ajax() in the following significant ways:
- The Promise returned from
fetch()won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, as soon as the server responds with headers, the Promise will resolve normally (with theokproperty of the response set to false if the response isn’t in the range 200–299), and it will only reject on network failure or if anything prevented the request from completing. - Unless
fetch()is called with thecredentialsoption set toinclude,fetch():- won’t send cookies in cross-origin requests
- won’t set any cookies sent back in cross-origin responses
- As of August 2018, the default credentials policy changed to same-origin. Firefox was also modified in version 61.0b13)
A basic fetch request is really simple to set up. Have a look at the following code:
fetch('http://example.com/movies.json')
.then((response) => response.json())
.then((data) => console.log(data));
Here we are fetching a JSON file across the network and printing it to the console. The simplest use of fetch() takes one argument — the path to the resource you want to fetch — and does not directly return the JSON response body but instead returns a promise that resolves with a Response object.
The Response object, in turn, does not directly contain the actual JSON response body but is instead a representation of the entire HTTP response. So, to extract the JSON body content from the Response object, we use the json() method, which returns a second promise that resolves with the result of parsing the response body text as JSON.
Note: See the Body section for similar methods to extract other types of body content.
Fetch requests are controlled by the connect-src directive of Content Security Policy rather than the directive of the resources it’s retrieving.
Supplying request options
The fetch() method can optionally accept a second parameter, an init object that allows you to control a number of different settings:
See fetch() for the full options available, and more details.
// Example POST method implementation:
async function postData(url = '', data = {}) {
// Default options are marked with *
const response = await fetch(url, {
method: 'POST', // *GET, POST, PUT, DELETE, etc.
mode: 'cors', // no-cors, *cors, same-origin
cache: 'no-cache', // *default, no-cache, reload, force-cache, only-if-cached
credentials: 'same-origin', // include, *same-origin, omit
headers: {
'Content-Type': 'application/json'
// 'Content-Type': 'application/x-www-form-urlencoded',
},
redirect: 'follow', // manual, *follow, error
referrerPolicy: 'no-referrer', // no-referrer, *no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url
body: JSON.stringify(data) // body data type must match "Content-Type" header
});
return response.json(); // parses JSON response into native JavaScript objects
}
postData('https://example.com/answer', { answer: 42 })
.then((data) => {
console.log(data); // JSON data parsed by `data.json()` call
});
Note that mode: "no-cors" only allows a limited set of headers in the request:
AcceptAccept-LanguageContent-LanguageContent-Typewith a value ofapplication/x-www-form-urlencoded,multipart/form-data, ortext/plain
Sending a request with credentials included
To cause browsers to send a request with credentials included on both same-origin and cross-origin calls, add credentials: 'include' to the init object you pass to the fetch() method.
fetch('https://example.com', {
credentials: 'include'
});
Note: Access-Control-Allow-Origin is prohibited from using a wildcard for requests with credentials: 'include'. In such cases, the exact origin must be provided; even if you are using a CORS unblocker extension, the requests will still fail.
Note: Browsers should not send credentials in preflight requests irrespective of this setting. For more information see: CORS > Requests with credentials.
If you only want to send credentials if the request URL is on the same origin as the calling script, add credentials: 'same-origin'.
// The calling script is on the origin 'https://example.com'
fetch('https://example.com', {
credentials: 'same-origin'
});
To instead ensure browsers don’t include credentials in the request, use credentials: 'omit'.
fetch('https://example.com', {
credentials: 'omit'
})
Uploading JSON data
Use fetch() to POST JSON-encoded data.
const data = { username: 'example' };
fetch('https://example.com/profile', {
method: 'POST', // or 'PUT'
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify(data),
})
.then((response) => response.json())
.then((data) => {
console.log('Success:', data);
})
.catch((error) => {
console.error('Error:', error);
});
Uploading a file
Files can be uploaded using an HTML <input type="file" /> input element, FormData() and fetch().
const formData = new FormData();
const fileField = document.querySelector('input[type="file"]');
formData.append('username', 'abc123');
formData.append('avatar', fileField.files[0]);
fetch('https://example.com/profile/avatar', {
method: 'PUT',
body: formData
})
.then((response) => response.json())
.then((result) => {
console.log('Success:', result);
})
.catch((error) => {
console.error('Error:', error);
});
Uploading multiple files
Files can be uploaded using an HTML <input type="file" multiple /> input element, FormData() and fetch().
const formData = new FormData();
const photos = document.querySelector('input[type="file"][multiple]');
formData.append('title', 'My Vegas Vacation');
let i = 0;
for (const photo of photos.files) {
formData.append(`photos_${i}`, photo);
i++;
}
fetch('https://example.com/posts', {
method: 'POST',
body: formData,
})
.then((response) => response.json())
.then((result) => {
console.log('Success:', result);
})
.catch((error) => {
console.error('Error:', error);
});
Processing a text file line by line
The chunks that are read from a response are not broken neatly at line boundaries and are Uint8Arrays, not strings. If you want to fetch a text file and process it line by line, it is up to you to handle these complications. The following example shows one way to do this by creating a line iterator (for simplicity, it assumes the text is UTF-8, and doesn’t handle fetch errors).
async function* makeTextFileLineIterator(fileURL) {
const utf8Decoder = new TextDecoder('utf-8');
const response = await fetch(fileURL);
const reader = response.body.getReader();
let { value: chunk, done: readerDone } = await reader.read();
chunk = chunk ? utf8Decoder.decode(chunk) : '';
const re = /n|r|rn/gm;
let startIndex = 0;
let result;
while (true) {
let result = re.exec(chunk);
if (!result) {
if (readerDone) break;
let remainder = chunk.substr(startIndex);
({ value: chunk, done: readerDone } = await reader.read());
chunk = remainder + (chunk ? utf8Decoder.decode(chunk) : '');
startIndex = re.lastIndex = 0;
continue;
}
yield chunk.substring(startIndex, result.index);
startIndex = re.lastIndex;
}
if (startIndex < chunk.length) {
// Last line didn't end in a newline char
yield chunk.substr(startIndex);
}
}
async function run() {
for await (const line of makeTextFileLineIterator(urlOfFile)) {
processLine(line);
}
}
run();
Checking that the fetch was successful
A fetch() promise will reject with a TypeError when a network error is encountered or CORS is misconfigured on the server-side, although this usually means permission issues or similar — a 404 does not constitute a network error, for example. An accurate check for a successful fetch() would include checking that the promise resolved, then checking that the Response.ok property has a value of true. The code would look something like this:
fetch('flowers.jpg')
.then((response) => {
if (!response.ok) {
throw new Error('Network response was not OK');
}
return response.blob();
})
.then((myBlob) => {
myImage.src = URL.createObjectURL(myBlob);
})
.catch((error) => {
console.error('There has been a problem with your fetch operation:', error);
});
Supplying your own request object
Instead of passing a path to the resource you want to request into the fetch() call, you can create a request object using the Request() constructor, and pass that in as a fetch() method argument:
const myHeaders = new Headers();
const myRequest = new Request('flowers.jpg', {
method: 'GET',
headers: myHeaders,
mode: 'cors',
cache: 'default',
});
fetch(myRequest)
.then((response) => response.blob())
.then((myBlob) => {
myImage.src = URL.createObjectURL(myBlob);
});
Request() accepts exactly the same parameters as the fetch() method. You can even pass in an existing request object to create a copy of it:
const anotherRequest = new Request(myRequest, myInit);
This is pretty useful, as request and response bodies can only be used once.
Making a copy like this allows you to effectively use the request/response again while varying the init options if desired.
The copy must be made before the body is read.
Note: There is also a clone() method that creates a copy. Both methods of creating a copy will fail if the body of the original request or response has already been read, but reading the body of a cloned response or request will not cause it to be marked as read in the original.
The Headers interface allows you to create your own headers object via the Headers() constructor. A headers object is a simple multi-map of names to values:
const content = 'Hello World';
const myHeaders = new Headers();
myHeaders.append('Content-Type', 'text/plain');
myHeaders.append('Content-Length', content.length.toString());
myHeaders.append('X-Custom-Header', 'ProcessThisImmediately');
The same can be achieved by passing an array of arrays or an object literal to the constructor:
const myHeaders = new Headers({
'Content-Type': 'text/plain',
'Content-Length': content.length.toString(),
'X-Custom-Header': 'ProcessThisImmediately'
});
The contents can be queried and retrieved:
console.log(myHeaders.has('Content-Type')); // true
console.log(myHeaders.has('Set-Cookie')); // false
myHeaders.set('Content-Type', 'text/html');
myHeaders.append('X-Custom-Header', 'AnotherValue');
console.log(myHeaders.get('Content-Length')); // 11
console.log(myHeaders.get('X-Custom-Header')); // ['ProcessThisImmediately', 'AnotherValue']
myHeaders.delete('X-Custom-Header');
console.log(myHeaders.get('X-Custom-Header')); // null
Some of these operations are only useful in ServiceWorkers, but they provide a much nicer API for manipulating headers.
All of the Headers methods throw a TypeError if a header name is used that is not a valid HTTP Header name. The mutation operations will throw a TypeError if there is an immutable guard (see below). Otherwise, they fail silently. For example:
const myResponse = Response.error();
try {
myResponse.headers.set('Origin', 'http://mybank.com');
} catch (e) {
console.log('Cannot pretend to be a bank!');
}
A good use case for headers is checking whether the content type is correct before you process it further. For example:
fetch(myRequest)
.then((response) => {
const contentType = response.headers.get('content-type');
if (!contentType || !contentType.includes('application/json')) {
throw new TypeError("Oops, we haven't got JSON!");
}
return response.json();
})
.then((data) => {
/* process your data further */
})
.catch((error) => console.error(error));
Guard
Since headers can be sent in requests and received in responses, and have various limitations about what information can and should be mutable, headers’ objects have a guard property. This is not exposed to the Web, but it affects which mutation operations are allowed on the headers object.
Possible guard values are:
none: default.request: guard for a headers object obtained from a request (Request.headers).request-no-cors: guard for a headers object obtained from a request created withRequest.modeno-cors.response: guard for a headers object obtained from a response (Response.headers).immutable: guard that renders a headers object read-only; mostly used for ServiceWorkers.
Note: You may not append or set the Content-Length header on a guarded headers object for a response. Similarly, inserting Set-Cookie into a response header is not allowed: ServiceWorkers are not allowed to set cookies via synthesized responses.
Response objects
As you have seen above, Response instances are returned when fetch() promises are resolved.
The most common response properties you’ll use are:
Response.status— An integer (default value 200) containing the response status code.Response.statusText— A string (default value «»), which corresponds to the HTTP status code message. Note that HTTP/2 does not support status messages.Response.ok— seen in use above, this is a shorthand for checking that status is in the range 200-299 inclusive. This returns a boolean value.
They can also be created programmatically via JavaScript, but this is only really useful in ServiceWorkers, when you are providing a custom response to a received request using a respondWith() method:
const myBody = new Blob();
addEventListener('fetch', (event) => {
// ServiceWorker intercepting a fetch
event.respondWith(
new Response(myBody, {
headers: { 'Content-Type': 'text/plain' }
})
);
});
The Response() constructor takes two optional arguments — a body for the response, and an init object (similar to the one that Request() accepts.)
Note: The static method error() returns an error response. Similarly, redirect() returns a response resulting in a redirect to a specified URL. These are also only relevant to Service Workers.
Body
Both requests and responses may contain body data. A body is an instance of any of the following types:
ArrayBufferTypedArray(Uint8Array and friends)DataViewBlobFileString, or a string literalURLSearchParamsFormData
The Request and Response interfaces share the following methods to extract a body. These all return a promise that is eventually resolved with the actual content.
Request.arrayBuffer()/Response.arrayBuffer()Request.blob()/Response.blob()Request.formData()/Response.formData()Request.json()/Response.json()Request.text()/Response.text()
This makes usage of non-textual data much easier than it was with XHR.
Request bodies can be set by passing body parameters:
const form = new FormData(document.getElementById('login-form'));
fetch('/login', {
method: 'POST',
body: form
});
Both request and response (and by extension the fetch() function), will try to intelligently determine the content type. A request will also automatically set a Content-Type header if none is set in the dictionary.
Feature detection
Fetch API support can be detected by checking for the existence of Headers, Request, Response or fetch() on the Window or Worker scope. For example:
if (window.fetch) {
// run my fetch request here
} else {
// do something with XMLHttpRequest?
}
Specifications
| Specification |
|---|
| Fetch Standard # fetch-method |
Browser compatibility
BCD tables only load in the browser
See also
|
29.05.2020, 15:11 |
|||
|
|||
|
ошибка 500 fetch Здравствуйте, возникла проблема. Я написал форму регистрации, которая успешно работает, после чего написал js файл, который обращается к серверу через fetch GET методом и всё ок. Но когда я сделал форму логина и повторил всё уже с методом POST, то сервер выдаёт ошибку 500, причём сама форма логина работает, однако если подключить js файл с fetch то случается error. Есть идеи с чем это может быть связано? <!DOCTYPE HTML>
<html>
<head>
<title>Login</title>
</head>
<body>
<form method="POST" action="https://test-publicapi.maximarkets.org/Account/logon">
<p>
<label>Login<br>
<input name="email" type="email" size="40" id="log">
</label>
</p>
<p>
<label>Password<br>
<input name="password" type="password" size="40" id="pass">
</label>
</p>
<p>
<button type="submit">Вход</button>
</p>
</form>
<script src="scriptforlog.js"></script>
</body>
</html>
Вот js файл async function onFormSubmit(evt) {
evt.preventDefault();
let email = document.getElementById('log').value;
let password = document.getElementById('pass').value;
let skip2Fa = true;
let data = new FormData();
data.append('email',email);
data.append('password',password);
data.append('skip2Fa',skip2Fa);
const response = await fetch(`https://test-publicapi.maximarkets.org/Account/logon`, {
method: "POST", body: data
});
if(response.ok) {
alert('ok');
} else {
alert('wrong');
};
}
const form = document.querySelector('form');
form.addEventListener('submit' , onFormSubmit);
|
|
30.05.2020, 03:49 |
||||
|
||||
Вы отправляете данные в разных форматах — когда отправляли напрямую через форму, то там был тип application/x-www-form-urlencoded, (такой же, как у текстового представления класса URLSearchParams), что очевидно принимается сервером. А класс FormData в конечном счёте представляет данные при отправке в виде типа multipart/form-data, а вам нужен application/x-www-form-urlencoded. Можно перевести из одного формата в другой, а можно сразу правильный. Например, замените (строка №8) FormData на URLSearchParams.
|
|
30.05.2020, 14:19 |
|||
|
|||
|
Спасибо, я уже понял что проблема была в формате данных, однако я решил проблему таким способом(добавил headers) function onFormSubmit(evt) {
evt.preventDefault();
let mail = document.getElementById('log').value;
let pass = document.getElementById('pass').value;
fetch('https://test-publicapi.maximarkets.org/Account/logon', {
method: 'POST',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json'
},
body: JSON.stringify({
email: mail,
password: pass,
})
});
}
const form = document.querySelector('form');
form.addEventListener('submit' , onFormSubmit);
|
|
30.05.2020, 18:09 |
||||
|
||||
А чем смешанный тип не подойдет? Статус 500, это в первую очередь нужно смотреть логи на сервере и устранять причину на нем.
|
|
04.06.2020, 02:53 |
||||||||||||||||||||
|
||||||||||||||||||||
Пусть имеется адрес «dimityr.novakov@gmil.com» и пароль «anybody!has@got#to$learn%sometime», которые нужно передать на сервер. Давайте посмотрим, как можно представить эти данные для передачи…
Т. к. передача файлов не нужна в данном случае, то наверно следует отдавать предпочтение менее многословному формату!
Многие общественные API могут такое возвращать, однако это скорей означает, что следует посылать данные в правильном формате.
|
|
04.06.2020, 08:09 |
||||
|
||||
Ой ли так это на самом деле? И остальное ну чушь полнейшая, ибо на то он и смешанный тип, и он никак не может стать причиной ошибки отправки им вместо application/x-www-form-urlencoded.
|
|
04.06.2020, 10:24 |
||||||||||||
|
||||||||||||
Какие предъявы? Посчитай байты!
Конечно же можешь посылать данные во всех возможных форматах, однако разработчики серверного кода могли написать только обработку, например, для типа json, а на всё остальное завершение со статусом 404 или 500 или найди ещё «Я — чайник!» или ещё что!
«Не хотим принимать такое — завершили как смогли!»
|
|
04.06.2020, 10:53 |
|||
|
|||
|
Слушай, гений ты наш, ты практически ответил на возможную причину ошибки тем, что вместо application/x-www-form-urlencoded отдается тип multipart/form-data, что является просто бредом. Все дальнейшие твои рассказы, это пересказ документации, которую я и без тебя знаю. И хотя бы поинтересовался каковы причины могут порождать статус 500, и корректно ли будет бездумно при этом выплевывать его клиенту, пусть мается в догадках. А то гонишь пургу, баз какой-то беспредметный.
|
|
04.06.2020, 11:26 |
||||||||||||
|
||||||||||||
Вам уже отвечали — неверный формат данных запроса. А чём вам не подходит ответ в формате JSON?
Я писал про отправку на сервер в формате multipart/form-data (и автор темы тоже), а не про отправку клиенту, которая кстати, происходит в формате JSON. И отправка клиенту статуса 500, а также сопутствующих данных тоже происходит в формате JSON… {
"errorType": 1,
"statusCode": 500,
"message": "Processing of the HTTP request resulted in an exception. Please see the HTTP response returned by the 'Response' property of this exception for details.",
"messageDetail": null,
"validationErrors": null,
"padString": null
}
Какой пересказ? Даже автор темы давно понял, что «проблема была в формате данных».
|
|
04.06.2020, 11:38 |
||||
|
||||
Значит так: если речь об API, то нормальный разработчик обязательно опишет параметры запроса, иначе, что вполне естественно, с API нельзя будет работать. В том что такое случилось скорее вина пользователя не удосужившегося прочесть документацию, и обнаружившего решение методом научного тыка. Ты же начал совсем с иного, что вообще никоим образом не могло быть источником проблемы. Все остальное, это ради поболтать. PS. Кстати, отвечать клиенту статусом 404 на ошибку несоответствия типу, это вообще из рук вон.
|
TJ VanToll
Quiz: What does this call to the web’s new fetch() API do?
If you’re like me, you might assume this code logs “error” when run—but it actually logs “ok”.
This expectation probably comes from years of jQuery development, as jQuery’s ajax() method invokes its fail handler when the response contains a failed HTTP status code. For example, the code below logs “error” when run:
Why does fetch() work this way?
Per MDN, the fetch() API only rejects a promise when a “network error is encountered, although this usually means permissions issues or similar.” Basically fetch() will only reject a promise if the user is offline, or some unlikely networking error occurs, such a DNS lookup failure.
The good is news is fetch provides a simple ok flag that indicates whether an HTTP response’s status code is in the successful range or not. For instance the following code logs “Error: Internal Server Error(…)”:
To keep this code DRY and reusable, you probably want to create a generic error handling function you can use for all of your fetch() calls. The following code refactors the error handling into a handleErrors() function:
For added fun you can use ES6 arrow functions to make the callback formatting a little less verbose:
Parting thoughts
Although I still don’t like fetch() ’s lack of rejecting failed HTTP status codes, over time fetch() ’s behavior has grown on me—mostly because it gives me more control over how I handle individual problems. Plus, the composable nature of fetch() makes it fairly trivial to manually handle errors without adding a bunch of verbose code.
Overall I think it’s worth taking few minutes to play with fetch() , even if it’s just to see what you think. It’s certainly a far more readable alternative to XMLHttpRequest. If you happen to be building NativeScript apps, you might not know that you can use fetch() today without any need for a polyfill or fallback. And something about using fetch() to perform HTTP requests in native Android and iOS apps is just plain cool 🙂
This article was updated on September 15th, 2015 to use a simpler handleErrors() function based on a comment from Jake Archibald.
Источник
Error 500 «fetch failed ()» at $fetchRaw2 #156
Comments
prescience-data commented Oct 28, 2022
On a new Nuxt 3 installation, the demo page that should load when loading pnpm run dev crashes with
Attempting to isolate, I have tried with the following variations: node@18 , node@19 , pnpm , npm , yarn — deleting the project and starting fresh each time, all with the same results.
Environment specifics that may be relevant:
- Ubuntu 22.04 (popOS!)
- volta node version manager
- Nuxt 3.0.0-rc.12 with Nitro 0.6.0
I can’t find any references to this issue on either the nuxt package or the intermediate h3 page which indirectly calls ohmyfetch , so given the error seems to emerge from $fetchRaw2 within the ohmyfetch package, thought it best to post here.
The text was updated successfully, but these errors were encountered:
tao commented Oct 28, 2022
I ran into this same problem on a brand new Nuxt 3.0.0-rc.12 install too. I tried Node v18 and v19 as I thought it was related to the fetch API warning that the CLI prints when you run the code.
It’s the same error line I’m getting.
prescience-data commented Oct 28, 2022
I worked out from the Node 16 error message that it’s due to an ipv6 issue (possibly downstream in Nuxt).
When you set scripts to run nuxt dev —host 127.0.0.1 it works, but that was super-non-obvious lol.
chrisnaadhi commented Nov 7, 2022
got same problem when using node v18
it’s all gone when using node v16, better stick with v16 for a while
Maximus1000 commented Nov 10, 2022 •
Edit: FIXED — No 500 with HTTPS and working SSL, fixed and working in a minimal repo as below by adding this to either .env or to the npm dev script:
Others discussed adding —host 0.0.0.0 as a loop back for an IPv6 issue (way over my head). I tried that and works fine. When I remove that host param or set it to anything else (e.g. something arbitrary like banana.test) and reload browser after full quit, I can still get SSL. So, that’s great. Hoping 500 fetch error gone in full.
So, SSL/HTTPS is working with rc13 and Node v18 with the above .env setting (or in script).
Nuxt3 authors seemed to suggest that you wouldn’t need the above line in I think RC11 or 12 but seems still needed for me. Hoping this helps someone else. Also cert made with mkcert. Both definition in dev script and in nuxt.config needed for me for SSL.
Original:
Same 500 fetch error. Fresh nuxt-rc13. Nothing else in it.
I’m wondering if anyone knows if I’m making a mistake on SSL / Certificate syntax in either config or package.json?
The error for me could be related to Node v18 (haven’t downgraded yet) or due to something else related to SSL cert.
I tried with variations on the dev script, e.g. —host 127.0.0.1 or localhost or blank, same error. When I remove the cert and cert-keys in dev script, no 500 error (Nuxt splash loads correctly) but now HTTP not HTTPS (SSL not accepted).
The config below is being accepted by Chrome for HTTPS.
SSL works in the above config (HTTPS accepted) and I get the 500 error.
With just dev: nuxt dev —https —host banana.test or any other params (excluding cert and cert-key), no 500, no HTTPS, and Nuxt splash loads correctly.
If anyone has any suggestions, much appreciated.
Источник
Javascript — fetch API and HTML error statuses
Don’t get caught out by this somewhat surprising interaction.
I was writing a GET request to an endpoint the other day and in my testing, I was receiving a lot of 400 errors. 400 errors are to do with client errors, basically errors caused by the person making the request. Some common 400 errors are;
— 400 Bad Request
— 401 Unauthorized
— 404 Not Found
— 418 I’m a teapot (Ok maybe not so much this one, but it is a real error code)
Now, this was absolutely fine, I had excepted to run into these errors. But what I didn’t expect was that my API Hook (in my case React-query) was firing the onSuccess method when the API response came back. Basically, my call was failing with a 400 error but my API management hook thought it was succeeding. Very odd.
At first, I suspected foul play in React-query, that somehow 400 errors were coded as successes even though that seemed crazy to me.
But after some digging, I found that it was actually the ‘fault’ of the fetch API. And as it turns out, this is not a fault at all, this is expected behavior. So how does fetch handle HTTP error statuses?
What is Success?
To some of you reading, this article may seem extremely obvious — I think this comes down to our own definitions of success. To me, success in an API context means something like;
1. We sent our request
2. The server responded
3. We were authorized for that request
4. Our request is carried out
5. Everything works as it should, we get a 200’s OK status 🥳
But this isn’t how fetch defines success. Fetch is only interested up to point 2. All that fetch cares about is if the network was able to carry out the request or not. Essentially, we can think of fetch working as such;
If you think like me, in that Success is basically synonymous with a 200 status, then this is a bit of a difficult concept to come to terms with. We can get back a 500 error but still be technically successful? Fetch says yes.
So how do we handle error statuses with fetch?
Let’s have a look at some code.
This getExample function returns a Promise which is the response of a simple GET fetch API request. If we were to consume this Promise with an API management library (such as React-query/Apollo ect) then they would tell us that this is a successful call, as the response Promise has not been failed. Remember — Fetch only fails the Promise on network error, not on error status. If we want to change this behavior, what we have to do is to manually fail/reject the Promise.
Thankfully, this is very simple. While fetch doesn’t fail the promise for us, it does set a response flag called ok to false if the returned error status is not 200–299. More on the response.Ok flag here — https://developer.mozilla.org/en-US/docs/Web/API/Response/ok
So with this in mind, we can write a check to see if that boolean flag has been set to false and if so we can manually fail the Promise. This should do the trick;
Recap
API Success !== 200 OK
Fetch doesn’t care about the error status as long as it gets a response from the server. We need to manually check and fail the response Promise if the code is not what we want it to be.
Or… we could just use Axios, which automatically does this for us.
Источник
Fetch — Error Handling for Failed HTTP Responses and Network Errors
This is a quick example of how to handle both network errors and HTTP errors (4xx or 5xx) for Fetch API ( fetch() ) requests in a single catch() block.
GET request with error handling
This sends an HTTP GET request to an invalid URL on the Reqres api which is a fake online REST api used for testing, then writes the error message to the parent of the #get-request-error-handling .total element and logs the error to the console.
Error Handling
The fetch() function will automatically throw an error for network errors but not for HTTP errors such as 4xx or 5xx responses. For HTTP errors we can check the response.ok property to see if the request failed and reject the promise ourselves by calling return Promise.reject(error); . This approach means that both types of failed requests — network errors and http errors — can be handled by a single catch() block instead of needing two separate pieces of error handling code.
JSON Check
The fetch .then() callback is passed the HTTP response object when the request is completed, the function checks if the response type is JSON before parsing the response body with the response.json() method, because calling response.json() will cause an error if the response doesn’t contain JSON data.
Subscribe or Follow Me For Updates
Subscribe to my YouTube channel or follow me on Twitter, Facebook or GitHub to be notified when I post new content.
Other than coding.
I’m currently attempting to travel around Australia by motorcycle with my wife Tina on a pair of Royal Enfield Himalayans. You can follow our adventures on YouTube, Instagram and Facebook.
Need Some Fetch Help?
Search fiverr to find help quickly from experienced Fetch developers.
Источник
Javascript — fetch API and HTML error statuses
Don’t get caught out by this somewhat surprising interaction.
I was writing a GET request to an endpoint the other day and in my testing, I was receiving a lot of 400 errors. 400 errors are to do with client errors, basically errors caused by the person making the request. Some common 400 errors are;
— 400 Bad Request
— 401 Unauthorized
— 404 Not Found
— 418 I’m a teapot (Ok maybe not so much this one, but it is a real error code)
Now, this was absolutely fine, I had excepted to run into these errors. But what I didn’t expect was that my API Hook (in my case React-query) was firing the onSuccess method when the API response came back. Basically, my call was failing with a 400 error but my API management hook thought it was succeeding. Very odd.
At first, I suspected foul play in React-query, that somehow 400 errors were coded as successes even though that seemed crazy to me.
But after some digging, I found that it was actually the ‘fault’ of the fetch API. And as it turns out, this is not a fault at all, this is expected behavior. So how does fetch handle HTTP error statuses?
What is Success?
To some of you reading, this article may seem extremely obvious — I think this comes down to our own definitions of success. To me, success in an API context means something like;
1. We sent our request
2. The server responded
3. We were authorized for that request
4. Our request is carried out
5. Everything works as it should, we get a 200’s OK status 🥳
But this isn’t how fetch defines success. Fetch is only interested up to point 2. All that fetch cares about is if the network was able to carry out the request or not. Essentially, we can think of fetch working as such;
If you think like me, in that Success is basically synonymous with a 200 status, then this is a bit of a difficult concept to come to terms with. We can get back a 500 error but still be technically successful? Fetch says yes.
So how do we handle error statuses with fetch?
Let’s have a look at some code.
This getExample function returns a Promise which is the response of a simple GET fetch API request. If we were to consume this Promise with an API management library (such as React-query/Apollo ect) then they would tell us that this is a successful call, as the response Promise has not been failed. Remember — Fetch only fails the Promise on network error, not on error status. If we want to change this behavior, what we have to do is to manually fail/reject the Promise.
Thankfully, this is very simple. While fetch doesn’t fail the promise for us, it does set a response flag called ok to false if the returned error status is not 200–299. More on the response.Ok flag here — https://developer.mozilla.org/en-US/docs/Web/API/Response/ok
So with this in mind, we can write a check to see if that boolean flag has been set to false and if so we can manually fail the Promise. This should do the trick;
Recap
API Success !== 200 OK
Fetch doesn’t care about the error status as long as it gets a response from the server. We need to manually check and fail the response Promise if the code is not what we want it to be.
Or… we could just use Axios, which automatically does this for us.
Источник