O Que o Axios Ainda Oferece em Relação ao Fetch
A Fetch API amadureceu significativamente. Está integrada em todos os navegadores modernos, disponível nativamente no Node.js desde a v18 através do Undici, e é capaz de lidar com JSON, cancelamento de requisições e streaming. Para muitas requisições de API no frontend, ela é genuinamente suficiente.
Então por que as equipas continuam a recorrer ao Axios? Não por hábito, mas porque o Axios ainda resolve problemas específicos da experiência do programador que o Fetch deixa por sua conta. É aqui que essa lacuna realmente se manifesta.
Pontos-Chave
- O Fetch resolve com sucesso em respostas 4xx e 5xx, forçando verificações manuais de
response.okem cada requisição. - Os interceptors do Axios centralizam preocupações transversais como tokens de autenticação, logging e normalização de erros sem boilerplate por requisição.
- A configuração partilhada via
axios.create()simplifica o trabalho com múltiplas APIs que necessitam de diferentes base URLs, headers ou timeouts. - O acompanhamento do progresso de uploads e as opções de timeout integradas continuam a ser exclusivos do Axios, algo que o Fetch não consegue igualar nativamente.
- Para projetos pequenos com necessidades mínimas de HTTP, o Fetch é a opção padrão correta, sem dependências.
Axios vs Fetch: Onde Estão as Diferenças Reais
1. Tratamento de Erros HTTP que Funciona por Padrão
O Fetch só rejeita em caso de falha de rede. Uma resposta 404 ou 500 resolve com sucesso — tem de verificar response.ok você mesmo todas as vezes.
// Fetch — tem de verificar manualmente
const res = await fetch('/api/user');
if (!res.ok) throw new Error(`HTTP error: ${res.status}`);
const data = await res.json();
// Axios — rejeita automaticamente em 4xx/5xx por padrão
const { data } = await axios.get('/api/user');
Em aplicações grandes com dezenas de endpoints, essa verificação manual torna-se em boilerplate repetitivo. O Axios elimina a maior parte disso por padrão.
2. Interceptors de Requisição e Resposta Integrados
Esta é a funcionalidade que a maioria dos programadores cita ao escolher o Axios. Os interceptors permitem anexar lógica — tokens de autenticação, logging, normalização de erros — uma única vez, globalmente, sem tocar em requisições individuais.
axios.interceptors.request.use(config => {
config.headers.Authorization = `Bearer ${getToken()}`;
return config;
});
axios.interceptors.response.use(
response => response,
error => {
if (error.response?.status === 401) redirectToLogin();
return Promise.reject(error);
}
);
Com o Fetch, pode simular isto envolvendo o fetch() numa função personalizada. Mas esse wrapper não é componível, não é empilhável, e é você que o tem de manter.
3. Configuração Partilhada com Instâncias do Axios
O Axios permite criar instâncias isoladas com base URLs, headers e timeouts predefinidos — um padrão genuinamente útil quando a sua aplicação comunica com múltiplas APIs.
const apiClient = axios.create({
baseURL: 'https://api.example.com',
timeout: 8000,
headers: { 'X-App-Version': '2.1.0' },
});
Replicar isto de forma limpa com Fetch requer uma classe wrapper ou uma factory function. É exequível, mas é mais escopo de que tem de tomar conta.
Discover how at OpenReplay.com.
4. Acompanhamento do Progresso de Uploads
O Fetch ainda não tem uma API nativa padronizada de progresso de upload nos navegadores. O Axios expõe onUploadProgress diretamente, suportado por XMLHttpRequest por baixo nos navegadores.
await axios.post('/upload', formData, {
onUploadProgress: e => {
if (e.total) {
console.log(`${Math.round((e.loaded / e.total) * 100)}%`);
}
},
});
Se precisa de progresso de upload numa configuração apenas com Fetch, terá de voltar ao XMLHttpRequest puro. Isso é uma regressão real.
5. Configuração de Timeout Sem o Boilerplate do AbortController
O Axios aceita uma opção timeout diretamente. O Fetch exige que configure manualmente AbortController e setTimeout — o que funciona, mas adiciona ruído.
// Axios
await axios.get('/api/data', { timeout: 5000 });
// Equivalente com Fetch
const controller = new AbortController();
const id = setTimeout(() => controller.abort(), 5000);
try {
const res = await fetch('/api/data', { signal: controller.signal });
} finally {
clearTimeout(id);
}
Os ambientes modernos também suportam AbortSignal.timeout(), que encurta isto consideravelmente, e o suporte nos navegadores já está amplamente disponível.
Comparação Rápida: Funcionalidades do Axios vs Fetch API
| Capacidade | Fetch | Axios |
|---|---|---|
| Rejeição de erros HTTP | Verificação manual de response.ok | Automática por padrão |
| Interceptors | Wrapper personalizado necessário | Integrados |
| Instâncias partilhadas | Padrão factory manual | axios.create() |
| Progresso de upload | Não suportado nativamente | onUploadProgress |
| Timeout de requisição | AbortController + setTimeout | Opção timeout |
| Tamanho do bundle | 0 KB (nativo) | ~15 KB gzipped |
Conclusão
O Fetch não é inadequado. Para clientes HTTP JavaScript simples — alguns endpoints, sem lógica de autenticação partilhada, sem progresso de upload — é a escolha padrão correta. Sem dependências, sem overhead.
Mas o Axios merece o seu lugar quando as suas requisições de API no frontend crescem em complexidade. Interceptors, instâncias partilhadas, tratamento automático de erros e progresso de upload não são funcionalidades de que sentirá falta até precisar delas — e nessa altura vai querê-las integradas, e não construídas à mão. É isso que o Axios ainda lhe oferece.
FAQs
Depende da complexidade do projeto. Para um punhado de requisições simples, o Fetch é suficiente e evita uma dependência. Para aplicações com autenticação partilhada, tratamento centralizado de erros, múltiplos clientes de API ou requisitos de progresso de upload, o Axios poupa boilerplate significativo que de outra forma teria de reimplementar você mesmo.
Parcialmente. Pode envolver o fetch numa função que injete headers ou trate erros, mas perde a natureza empilhável e componível dos interceptors do Axios. Cada nova preocupação exige modificar o wrapper diretamente, e encadear múltiplos interceptors independentes torna-se complicado. A maioria das equipas que tentam isto acaba por reconstruir uma versão mais pequena e menos testada do Axios.
Não exatamente. O Axios suporta progresso de upload e download no Node.js, mas a implementação difere dos navegadores porque o Node não usa XMLHttpRequest. Os eventos de progresso nos navegadores são geralmente mais suaves e granulares, enquanto alguns cenários de upload no Node.js — especialmente uploads com FormData — têm limitações dependendo do adaptador e do runtime.
Ambas são sólidas. O ky é um pequeno wrapper baseado em Fetch que adiciona retries, hooks e timeouts mantendo-se leve. O got é rico em funcionalidades, mas apenas para Node. O Axios continua popular porque funciona tanto em ambientes de navegador como Node com uma única API, tem amplo suporte do ecossistema e é familiar à maioria dos programadores JavaScript.
Complete picture for complete understanding
Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.
Check our GitHub repo and join the thousands of developers in our community.