Что значит поле response.ok и зачем его проверять в fetch API

Что проверяют

Знаете ли, что fetch считает успехом, и понимаете ли его главную особенность: ответ с кодом ошибки для него это нормально выполненный запрос. Сюда же тянется вся тема обработки ошибок сети.

Как отвечать

response.ok это булево поле объекта Response, истинное, когда статус лежит в диапазоне от 200 до 299 включительно. Проверять его нужно потому, что промис fetch отклоняется только при сетевом сбое, отказе CORS или отмене через AbortController. Ответ 404 или 500 приходит как успешно выполненный запрос, и без проверки код пойдёт разбирать тело ошибки как ожидаемые данные.

const res = await fetch(url);
if (!res.ok) {
  throw new Error(`Запрос не удался: ${res.status}`);
}
const data = await res.json();

Детали, которые отличают уверенный ответ:

• переходы по редиректам идут прозрачно, ok относится к последнему ответу в цепочке, а признак переходов лежит в res.redirected;
• 304 в диапазон не входит, так что ok будет ложным, хотя содержимое браузер подставит из кэша сам;
• при режиме no-cors ответ непрозрачный: статус 0, ok ложно, тело недоступно;
• тело читается один раз; если нужно и разобрать JSON, и показать исходный текст, делают res.clone();
• в теле ошибки обычно лежит код и человекочитаемое сообщение, его стоит доставать и показывать.

Где спотыкаются

Ставят catch и считают, что ошибки закрыты. В catch попадут только сетевые сбои, а 500 спокойно пройдёт дальше по цепочке и обвалится уже внутри разбора данных.

Второе: строят сообщение на statusText. В HTTP/2 пояснительной фразы в ответе нет вовсе, поле приходит пустым; опираться надо на status и на тело.

Третье: зовут res.json() до проверки. Страница ошибки часто отдаёт HTML, разбор падает с синтаксической ошибкой, и в логе видно не код 500, а невнятную жалобу на неожиданный символ.