Felhantering och Rate Limiting

När ett fel uppstår returnerar API:et ett standardiserat fel-svar i följande format:

{
  "_status": "ERR",
  "_error": {
    "code": 422,
    "message": "Validation failed",
    "details": {
      "customer.name": "Name is required",
      "customer.id_number": "Invalid ID number format"
    }
  }
}

Vanliga HTTP Status Codes

• 200 OK: Request lyckades
• 201 Created: Resurs skapad framgångsrikt
• 400 Bad Request: Ogiltig request-data
• 401 Unauthorized: Autentisering krävs eller ogiltig
• 403 Forbidden: Otillräckliga behörigheter
• 404 Not Found: Resurs hittades inte
• 422 Unprocessable Entity: Valideringsfel
• 500 Internal Server Error: Serverfel

Bästa praxis för felhantering

1. Kontrollera alltid response status

   • Kontrollera både HTTP status code och _status fält
   • Hantera både lyckade och felaktiga responses

2. Implementera korrekt felåterhämtning

   • Försök igen vid tillfälliga fel (t.ex. rate limits)
   • Logga fel för felsökning
   • Ge meningsfulla felmeddelanden till slutanvändare

3. Hantera specifika felkoder

   • 401: Autentisera igen och försök igen
   • 422: Validera indata
   • 429: Implementera backoff-strategi
   • 5xx: Överväg circuit breaker-mönster

4. Validerings bästa praxis

   • Validera data innan sändning
   • Kontrollera obligatoriska fält
   • Verifiera dataformat
   • Säkerställ efterlevnad av affärsregler

Rate Limiting

Rate limiting är implementerat för att säkerställa systemstabilitet. Hantera rate limiting smidigt med exponentiell backoff

• Standard rate limit: 100 requests per minut per API-nyckel
• Burst limit: 10 requests per sekund
• Rate limit headers ingår i responses