Foutafhandeling
Deze pagina beschrijft de HTTP statuscodes, foutrespons formaten en best practices voor het afhandelen van fouten in de Flixer API.HTTP Statuscodes
| Code | Status | Beschrijving |
|---|---|---|
| 200 | OK | Het verzoek is succesvol verwerkt |
| 201 | Created | De resource is succesvol aangemaakt |
| 400 | Bad Request | Het verzoek bevat ongeldige parameters |
| 401 | Unauthorized | Authenticatie is vereist of is mislukt |
| 403 | Forbidden | De gebruiker heeft geen toestemming voor deze actie |
| 404 | Not Found | De aangevraagde resource bestaat niet |
| 422 | Unprocessable Entity | De aanvraaggegevens zijn syntactisch correct maar semantisch ongeldig |
| 500 | Internal Server Error | Er is een onverwachte serverfout opgetreden |
Foutresponse Formaat
Alle API-foutresponsen volgen een gestandaardiseerd formaat:code— Machine-readable foutcode (bijv.INVALID_REQUEST,UNAUTHORIZED,FORBIDDEN)message— Gebruikersvriendelijke foutbeschrijving in Nederlandsdetails— Aanvullende informatie over de fout (optioneel, vooral voor validatiefouten)timestamp— ISO 8601 tijdstempel van wanneer de fout optradrequestId— Uniek ID voor het verzoek (handig voor debuggen)
Veelvoorkomende Fouten
401 — Unauthorized (Niet Geauthenticeerd)
Oorzaken:- Geen geldige Bearer token in de
Authorization-header - Token is verlopen
- Token is ongeldig of beschadigd
- Zorg ervoor dat je een geldige token stuurt in de header:
- Controleer de vervaldatum van de token
- Verkrijg een nieuwe token via het
/auth/loginendpoint - Implementeer automatische token vernieuwing (zie refresh token flow)
403 — Forbidden (Geen Toestemming)
Oorzaken:- De gebruiker is geauthenticeerd maar heeft geen toestemming voor deze actie
- De gebruiker heeft onvoldoende rollen of permissies
- De brand/tenant is niet gelinkt aan de gebruiker
- Controleer of de gebruiker de juiste rol heeft (bijv.
admin,technician) - Verifieer dat de geselecteerde brand correct is ingesteld via de
X-Request-As-Brand-Membersheader - Contacteer een administrator om de benodigde permissies toe te wijzen
422 — Unprocessable Entity (Validatiefout)
Oorzaken:- Verplichte velden ontbreken
- Veldwaarden hebben het verkeerde format (bijv. ongeldig e-mailadres)
- Veldwaarden voldoen niet aan validatieregels
- Logische validatie is mislukt (bijv. einddatum vóór startdatum)
- Controleer de error response op de
detailssectie met veldnamen - Valideer invoergegevens aan clientzijde voordat je ze stuurt
- Implementeer client-side validatie met dezelfde regels als de server
- Lees de API documentatie voor veldvereisten
500 — Internal Server Error (Serverfout)
Oorzaken:- Een onverwachte fout in de servertoepassing
- Databaseverbindingsfout
- Externe service is niet beschikbaar
- Serverresources zijn uitgeput
- Deze fouten zijn meestal tijdelijk — implementeer retry logic met exponential backoff
- Controleer de API status pagina voor bekend onderhoud
- Wacht enkele seconden en probeer opnieuw
- Als het probleem aanhoudt, stuur het
requestIdnaar de support team - Implementeer fallback logica in je applicatie
Foutafhandeling in Code
JavaScript/TypeScript
Basis foutafhandeling
Met token vernieuwing
Python
Basis foutafhandeling
Met retry strategie
Retry Strategie
Implementeer exponential backoff retry logica voor 5xx fouten en bepaalde 4xx fouten (429, 408):Exponential Backoff Richtlijnen
JavaScript Implementatie
Waarschuwing: Implementeer retry logica alleen voor idempotente operaties (GET, HEAD, OPTIONS, PUT met dezelfde payload). Wees voorzichtig met POST verzoeken — alleen hergeven als je zeker weet dat het veilig is om te herhalen. Voeg altijd een jitter toe (willekeurige vertraging) tussen pogingen om “thundering herd” problemen te voorkomen.
Best Practices
- Altijd foutafhandeling implementeren — Veronderstel niet dat alle verzoeken slagen
- Token vernieuwing automatiseren — Implementeer refresh token logica in je HTTP client
- Gebruikersvriendelijke foutmeldingen — Toon gefilterde foutmeldingen aan eindgebruikers (niet alle technische details)
- Logging — Log alle API fouten met
requestIdvoor debugging - Exponential backoff — Implementeer retry logica voor transiente fouten (5xx, 429, 408)
- Request ID tracering — Bewaar
requestIduit foutresponses voor support - Timeouts — Stel altijd HTTP request timeouts in (bijv. 30 seconden)
- Idempotency — Gebruik idempotency keys voor POST verzoeken waar mogelijk