Ответ 1
Говоря простыми словами, это больше контрольная точка для каждого действия http. Каждый вызов API, который был сделан, проходит через этот перехватчик.
Итак, почему два перехватчика?
Вызов API состоит из двух половин: запроса и ответа. Поскольку он ведет себя как контрольная точка, запрос и ответ имеют отдельные перехватчики.
Некоторые случаи использования перехватчика запроса -
Предположим, вы хотите проверить перед тем, как сделать запрос, действительны ли ваши учетные данные? Таким образом, вместо того, чтобы фактически сделать вызов API, вы можете проверить его на уровне перехватчика, которые являются действительными вашими учетными данными.
Предположим, вам нужно прикрепить токен к каждому выполненному запросу, вместо дублирования логики добавления токена при каждом вызове axios, вы можете создать перехватчик, который присоединяет токен к каждому выполненному запросу.
Некоторые варианты использования перехватчика ответа -
Предположим, что вы получили ответ, и, судя по API-ответам, которые вы хотите определить, что пользователь вошел в систему. Таким образом, в перехватчике ответов вы можете инициализировать класс, который обрабатывает пользователя, вошедшего в систему, и обновлять его соответствующим образом для объекта ответа, который вы используете. получил.
Предположим, вы запросили некоторые API с действительными учетными данными API, но у вас нет действительной роли для доступа к данным. Таким образом, вы можете вызвать предупреждение от перехватчика ответа о том, что пользователь не разрешен. Таким образом, вы будете защищены от несанкционированной обработки ошибок API, которую вам придется выполнять при каждом запросе Axios, который вы сделали.
Могли бы придумать эти варианты использования прямо сейчас.
Надеюсь, это поможет :)
EDIT
Поскольку этот ответ набирает обороты, вот несколько примеров кода
Перехватчик запроса
=> Можно напечатать объект конфигурации axios (если необходимо), выполнив (в этом случае, проверив переменную окружения):
const DEBUG = process.env.NODE_ENV === "development";
axios.interceptors.request.use((config) => {
/** In dev, intercepts request and logs it into console for dev */
if (DEBUG) { console.info("✉️ ", config); }
return config;
}, (error) => {
if (DEBUG) { console.error("✉️ ", error); }
return Promise.reject(error);
});
=> Если кто-то хочет проверить, какие передаваемые заголовки/добавить более общие заголовки, он доступен в объекте config.headers. Например:
axios.interceptors.request.use((config) => {
config.headers.genericKey = "someGenericValue";
return config;
}, (error) => {
return Promise.reject(error);
});
=> В случае запроса GET отправляемые параметры запроса можно найти в объекте config.params.
Перехватчик ответа
=> Вы даже можете опционально проанализировать ответ API на уровне перехватчика и передать проанализированный ответ вниз вместо исходного ответа. Это может сэкономить вам время на написание логики синтаксического анализа снова и снова, если API используется одинаково в нескольких местах. Один из способов сделать это - передать дополнительный параметр в api-request и использовать тот же параметр в перехватчике ответов для выполнения вашего действия. Например:
//Assume we pass an extra parameter "parse: true"
axios.get("/city-list", { parse: true });
Однажды в перехватчике ответа мы можем использовать его следующим образом:
axios.interceptors.response.use((response) => {
if (response.config.parse) {
//perform the manipulation here and change the response object
}
return response;
}, (error) => {
return Promise.reject(error.message);
});
Итак, в этом случае, когда в response.config есть объект parse, манипулирование выполняется, в остальных случаях оно будет работать как есть.
=> Вы даже можете просмотреть поступающие коды HTTP, а затем принять решение. Например:
axios.interceptors.response.use((response) => {
if(response.status === 401) {
alert("You are not authorized");
}
return response;
}, (error) => {
if (error.response && error.response.data) {
return Promise.reject(error.response.data);
}
return Promise.reject(error.message);
});