Axios i Node.js för stabila API-anrop och tydlig felhantering

När en Node.js-tjänst ska hämta data från ett API vill du kunna hantera svar, fel och tidsgränser utan att bygga hela HTTP-flödet själv. Axios från npm är ett vanligt val, men rätt inställningar beror bland annat på om anropet körs på servern eller i webbläsaren.

Installera Axios och välj rätt import för Node.js

Terminalkommandot är kort, men paketet hamnar i projektet där kommandot körs. Kör npm install axios från projektets rotmapp så att beroendet registreras i package.json och den exakta upplösta versionen sparas i låsfilen.

Med ES-moduler importerar du standardexporten med import axios from 'axios';. I CommonJS används const axios = require('axios');. npm-paketet innehåller TypeScript-typer, så ett separat typdefinitionspaket behövs normalt inte. Aktuell publicerad version syns på Axios på npm; jag tycker att en versionssida är en bättre kontrollpunkt än att kopiera ett versionsnummer från ett gammalt kodexempel.

Om projektet redan har en package-lock.json och du vill installera exakt det som låsfilen anger i CI, använd npm ci. Skillnaden är användbar: npm install kan uppdatera låsfilen, medan npm ci installerar den låsta beroendegrafen och misslyckas om manifestet och låsfilen inte stämmer överens.

En Axios-instans håller API-inställningarna samlade

Ett API-anrop kan fungera på din dator och ändå misslyckas i produktion om basadress eller tidsgräns skiljer sig mellan miljöerna. En egen instans samlar återkommande inställningar, så varje anrop slipper bära med sig samma konfiguration.

import axios from 'axios';

const api = axios.create({
  baseURL: process.env.API_BASE_URL,
  timeout: 5000,
  headers: {
    Accept: 'application/json'
  }
});

const { data } = await api.get('/products');

baseURL gör att relativa sökvägar som /products pekar mot samma API, medan timeout sätter en gräns för hur länge klienten väntar på svar. Miljövariabeln behöver finnas i servermiljön; i Node.js går det inte att förutsätta att en variabel från frontendens byggverktyg automatiskt blir tillgänglig.

Håll också hemliga API-nycklar på serversidan. En Axios-instans i frontendkod kan göra anropet bekvämt, men den döljer inte en nyckel som skickas till webbläsaren.

HTTP-status, nätverksfel och timeout kräver olika felsökning

Ett misslyckat anrop säger inte automatiskt vad som gick fel. Axios avvisar som standard svar utanför 2xx-serien, men ett nätverksavbrott kan inträffa innan servern ens skickar en statuskod.

Du kan använda axios.isAxiosError(error) för att typkontrollera Axios-fel i TypeScript och läsa statusen innan du bestämmer hur gränssnittet ska reagera. Jag tycker att det är säkrare att visa användaren ett begränsat felmeddelande och logga tekniska detaljer separat, särskilt när felobjektet kan innehålla URL:er eller headers.

En timeout på fem sekunder i exemplet är en inställning, inte en garanti för att alla API-anrop bör avbrytas då. Ett snabbt sökfilter och en filuppladdning har olika väntetider; välj gränsen efter vad anropet faktiskt gör.

Interceptors passar för gemensam logik, men kan dölja fel

När många anrop behöver samma behandling kan en interceptor fånga begäran eller svar innan resten av programmet hanterar dem. Det passar exempelvis för att lägga till en begärande header eller standardisera loggning, men en interceptor som sväljer fel gör felsökningen svårare.

api.interceptors.response.use(
  response => response,
  error => {
    console.error('API-anrop misslyckades', error.code);
    return Promise.reject(error);
  }
);

Här loggas felkoden, men felet skickas vidare genom Promise.reject. Om hanteraren i stället returnerar ett vanligt värde kan anropande kod felaktigt uppfatta svaret som lyckat. Axios dokumenterar även instanskonfiguration, timeouts och interceptors i projektets README.

Om varje API-anrop har olika autentisering eller olika felbeteende blir en global interceptor lätt för bred. Håll då logiken nära den Axios-instans eller tjänst som behöver den.

Två Axios-versioner från mars 2026 kräver en särskild kontroll

Versionsnummer berättar inte hela historien när en publicering har manipulerats. Den 31 mars 2026 publicerades axios@1.14.1 och axios@0.30.4 med den skadliga beroendepaketen plain-crypto-js@4.2.1, enligt CISA:s säkerhetsvarning.

Om låsfilen innehåller någon av de versionerna, eller beroendet plain-crypto-js, räcker det inte att bara installera en ren version och gå vidare. Axios-projektets efteranalys beskriver händelsen och rekommenderar att berörda miljöer hanteras som en möjlig kompromettering.

1. Sök i package-lock.json, andra låsfiler och CI-loggar efter versionsnumren och beroendepaketet.
2. Kontrollera om installation eller uppdatering skedde under exponeringstiden den 31 mars 2026.
3. Om en komprometterad version installerades, behandla utvecklardatorer och byggmiljöer som potentiellt exponerade, granska dem och byt hemligheter som kan ha varit åtkomliga.
4. Installera en kontrollerad, ren version och skapa om distributionen från en granskad låsfil.

Det här är en av anledningarna till att package-lock.json bör versionshanteras och att automatiska uppdateringar inte bör passera obemärkt. Jag skulle låta CI installera från låsfilen och granska säkerhetsmeddelanden innan ett stort beroende uppdateras.

Låt låsfilen och felhanteringen bära jobbet

För ett vanligt Node.js-projekt räcker en liten Axios-instans ofta långt: bestämd basadress, rimlig timeout och felhantering som skiljer serverfel från nätverksproblem. Lägg till interceptors först när flera anrop faktiskt behöver samma behandling.

Om ett anrop plötsligt slutar fungera, börja med felobjektet och låsfilen innan du skriver om klienten. En tydlig felorsak och en granskad beroendeversion ger oftast en bättre start än ännu ett lager specialkod.