Комментарии 11
А еще некоторые индивиды возвращают 200, при этом отображая код ошибки внутри самого тела запроса.
{
code: 404,
data: {}
}
Был у нас такой прикол с интеграцией стороннего сервиса.
В таком случае приходится еще и на code проверять 😂
Ну, технически никто не запрещает, имеют право. Главное чтобы это было хорошо задокументировано.
Ну, иногда полезно отличать отсутствие запрошеного объекта от временной пропажи сервера
Для этого семантичнее было бы возвращать 503 (Service Unavailable), т.к. статусы 4xx сигналят про ошибку клиента, а не временную проблему сервера. С точки зрения HTTP, раз за разом повторять запрос, вернувший 4хх в надежде на изменение - это безумие.
Если http это только транспорт то все правильно. А транспортом может быть к примеру и вебсокет
И кстати если дублировать код в http то уже на фронте приходится код дополнительно проверять - так как кодом может ответить какая-то прокся
Статус-коды HTTP в сообщении на веб-сокетах - это сюр.
Где вы увидели что написал про коды-http в веб-сокетах? Есть ошибки которые возвращает сервер приложения, они не обязательно должны быть совместимы с кодами-http. HTTP используется как транспорт, также как TCP/IP для HTTP. Вы же не используете коды ошибок TCP/IP в HTTP
По уму надо не просто какую-то фихню строковую вернуть, а то, что прислал сервер. Но добавить туда код ответа:
if (res.ok) {
return res.json();
}
return res.json()
.then((error) => {
// Добавляем свойство с заведомо не имеющимся в ответе сервера именем для кода ошибки
error.httpResponseCode = res.status;
return Promise.reject(error);
}
Почему важно проверять response.ok в Fetch API и почему HTTP-ошибки не вызывают отклонение промисов