Robuste Didit API-Integrationen in Go: Fehlerbehandlung und Wiederholungsstrategien (DE)

Didit's Ratenbegrenzungen verstehenImplementieren Sie clientseitige Drosselung und exponentielles Backoff für 429-Antworten, indem Sie die Header X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset nutzen, um Dienstunterbrechungen zu vermeiden.

Fehlertypen unterscheidenUnterscheiden Sie zwischen transienten (z. B. Netzwerkprobleme, Dienstausfall) und permanenten Fehlern (z. B. ungültige API-Schlüssel, fehlerhafte Anfragen), um die geeignete Wiederholungslogik anzuwenden oder schnell zu scheitern.

Robuste Wiederholungsmechanismen implementierenVerwenden Sie strukturierte Wiederholungsschleifen mit exponentiellem Backoff, Jitter und maximalen Wiederholungsversuchen, um transiente Fehler elegant zu behandeln und die Zuverlässigkeit kritischer Operationen wie der Sitzungserstellung zu verbessern.

Didits entwicklerfreundlicher Ansatz vereinfacht die IntegrationDidit bietet klare API-Dokumentationen, spezifische Ratenbegrenzungs-Header und eine modulare Architektur, die Go-Entwicklern den einfachen und sicheren Aufbau widerstandsfähiger Identitätsprüfungsabläufe ermöglicht.

Die Integration von APIs von Drittanbietern ist ein Eckpfeiler der modernen Anwendungsentwicklung, und die Identitätsprüfung bildet da keine Ausnahme. Beim Arbeiten mit kritischen Diensten wie der Identitätsplattform von Didit ist es von größter Bedeutung, dass Ihre Integration widerstandsfähig gegenüber Netzwerkschwankungen, Dienstausfällen und Ratenbegrenzungen ist. Dieser Leitfaden befasst sich mit fortgeschrittenen Strategien zur Fehlerbehandlung und Wiederholung, die speziell auf Didit API-Integrationen mit Go zugeschnitten sind, und hilft Ihnen beim Aufbau robuster und zuverlässiger Systeme.

Didits API-Fehlerlandschaft verstehen

Bevor Sie eine Wiederholungslogik implementieren, ist es entscheidend, die Arten von Fehlern zu verstehen, denen Sie begegnen könnten. Die Didit API kommuniziert, wie viele gut gestaltete Dienste, verschiedene Zustände über HTTP-Statuscodes. Während standardmäßige 2xx-Codes den Erfolg anzeigen, konzentrieren Sie sich hauptsächlich auf 4xx (Client-Fehler) und 5xx (Server-Fehler) und insbesondere auf 429 (Too Many Requests).

Didits Ratenbegrenzung und was sie für Sie bedeutet

Didit erzwingt Ratenbegrenzungen, um die API-Stabilität zu gewährleisten. Dies ist ein kritischer Aspekt, den Sie in Ihrer Integration verwalten müssen. Beispielsweise haben GET-Endpunkte typischerweise ein globales Limit von 300 Anfragen pro Minute pro Anwendung, wobei spezifische Endpunkte wie session-decision (100 U/min) oder session-v2-create (600 U/min) ihre eigenen, potenziell strengeren Limits haben. Wenn Sie eine Ratenbegrenzung erreichen, antwortet Didit mit dem Statuscode 429 Too Many Requests und enthält hilfreiche Header:

• X-RateLimit-Limit: Die maximale Anzahl von Anfragen, die im aktuellen Fenster erlaubt sind.
• X-RateLimit-Remaining: Die Anzahl der verbleibenden Anfragen im aktuellen Fenster.
• X-RateLimit-Reset: Die Zeit (in Epoch-Sekunden), zu der das aktuelle Ratenbegrenzungsfenster zurückgesetzt wird.
• Retry-After: (Oft enthalten) Die Anzahl der Sekunden, die gewartet werden soll, bevor eine weitere Anfrage gestellt wird.

Ihr Go-Client sollte diese Header aktiv überwachen. Wenn X-RateLimit-Remaining unter einen bestimmten Schwellenwert fällt (z. B. 15 % von X-RateLimit-Limit), sollten Sie Ihre Anfragen proaktiv drosseln. Das Ignorieren dieser kann zu anhaltenden 429-Fehlern führen, die die Fähigkeit Ihrer Anwendung beeinträchtigen, Verifizierungssitzungen zu erstellen oder Ergebnisse von Produkten wie Didits ID-Verifizierung oder AML-Screening abzurufen.

Implementierung robuster Wiederholungsstrategien mit exponentiellem Backoff in Go

Für transiente Fehler (z. B. Netzwerk-Timeouts, vorübergehende Dienstausfälle oder 429er) sind Wiederholungen unerlässlich. Naive Wiederholungen können jedoch Probleme verschärfen. Der Goldstandard ist exponentielles Backoff mit Jitter.

Exponentielles Backoff mit Jitter

Exponentielles Backoff bedeutet, die Wartezeit zwischen Wiederholungen exponentiell zu erhöhen. Jitter (Hinzufügen einer kleinen zufälligen Verzögerung) verhindert ein „Thundering Herd“-Problem, bei dem viele Clients nach einem Ausfall gleichzeitig erneut versuchen und den Dienst erneut überfordern. Hier ist ein konzeptionelles Go-Beispiel:

package main

import (
	"fmt"
	"io/ioutil"
	"net/http"
	"time"
	"math/rand"
)

func callDiditAPIWithRetry(url string, maxRetries int) ([]byte, error) {
	client := &http.Client{Timeout: 10 * time.Second}
	rand.Seed(time.Now().UnixNano())

	for i := 0; i <= maxRetries; i++ {
		resp, err := client.Get(url)
		if err != nil {
			// Handle network errors (e.g., connection refused, timeout)
			fmt.Printf("Attempt %d: Network error: %v\n", i+1, err)
			if i == maxRetries {
				return nil, fmt.Errorf("failed after %d retries: %w", maxRetries, err)
			}
			sleepTime := time.Duration(1<<i)*time.Second + time.Duration(rand.Intn(1000))*time.Millisecond // Exponential backoff + jitter
			fmt.Printf("Retrying in %v...\n", sleepTime)
			time.Sleep(sleepTime)
			continue
		}
		defer resp.Body.Close()

		switch resp.StatusCode {
		case http.StatusOK:
			fmt.Printf("Attempt %d: Success!\n", i+1)
			return ioutil.ReadAll(resp.Body)
		case http.StatusTooManyRequests:
			// Respect Retry-After header if present
			retryAfter := resp.Header.Get("Retry-After")
			if retryAfter != "" {
				if sleepSeconds, err := time.ParseDuration(retryAfter + "s"); err == nil {
					fmt.Printf("Attempt %d: Rate limited. Retrying after %v.\n", i+1, sleepSeconds)
					time.Sleep(sleepSeconds)
					continue
				}
			}
			// Fallback to exponential backoff if Retry-After is missing or invalid
			fmt.Printf("Attempt %d: Rate limited (429).\n", i+1)
			if i == maxRetries {
				return nil, fmt.Errorf("rate limited after %d retries", maxRetries)
			}
			sleepTime := time.Duration(1<<i)*time.Second + time.Duration(rand.Intn(1000))*time.Millisecond
			fmt.Printf("Retrying in %v...\n", sleepTime)
			time.Sleep(sleepTime)
			continue
		case http.StatusInternalServerError, http.StatusBadGateway, http.StatusServiceUnavailable, http.StatusGatewayTimeout:
			// Server-side errors that might be transient
			fmt.Printf("Attempt %d: Server error %d. Retrying.\n", i+1, resp.StatusCode)
			if i == maxRetries {
				return nil, fmt.Errorf("server error %d after %d retries", resp.StatusCode, maxRetries)
			}
			sleepTime := time.Duration(1<<i)*time.Second + time.Duration(rand.Intn(1000))*time.Millisecond
			fmt.Printf("Retrying in %v...\n", sleepTime)
			time.Sleep(sleepTime)
			continue
		default:
			// Non-retryable errors (4xx client errors, etc.)
			body, _ := ioutil.ReadAll(resp.Body)
			return nil, fmt.Errorf("non-retryable API error: %d %s, response: %s", resp.StatusCode, resp.Status, string(body))
		}
	}
	return nil, fmt.Errorf("unexpected control flow") // Should not be reached
}

func main() {
	// Example usage: Replace with actual Didit API endpoint
	// For a real integration, you'd be POSTing to /v3/session/ or similar
	// and handling the verification_url.
	apiURL := "https://verification.didit.me/health"
	data, err := callDiditAPIWithRetry(apiURL, 5)
	if err != nil {
		fmt.Println("Failed to call API:", err)
	} else {
		fmt.Println("API Response:", string(data))
	}
}

Dieses Snippet demonstriert, wie Netzwerkfehler, 429er (unter Berücksichtigung von Retry-After) und gängige 5xx-Fehler mit exponentiellem Backoff und Jitter behandelt werden. Es zeigt auch, wie man bei nicht wiederholbaren 4xx-Fehlern, die typischerweise auf falsche Eingaben zurückzuführen sind und sich bei einem erneuten Versuch nicht beheben lassen, schnell scheitert. Dies ist entscheidend für Operationen wie die Erstellung einer Verifizierungssitzung mithilfe der modularen Architektur von Didit.

Implementierung eines Circuit Breaker Musters

Während Wiederholungen bei transienten Problemen helfen, kann das kontinuierliche Wiederholen eines fehlerhaften Dienstes diesen weiter überlasten oder Ressourcen verschwenden, wenn der Dienst wirklich ausgefallen ist. Hier kommt das Circuit Breaker Muster ins Spiel. Ein Circuit Breaker überwacht Fehler, und wenn diese einen bestimmten Schwellenwert erreichen, „öffnet“ er den Stromkreis und verhindert weitere Anfragen für einen bestimmten Zeitraum. Nach diesem Zeitraum erlaubt er einige Testanfragen, um zu sehen, ob der Dienst wiederhergestellt ist.

In Go können Sie Bibliotheken wie sony/gobreaker verwenden, um dieses Muster zu implementieren:

package main

import (
	"errors"
	"fmt"
	"io/ioutil"
	"net/http"
	"time"

	"github.com/sony/gobreaker"
)

var cb *gobreaker.CircuitBreaker

func init() {
	st := gobreaker.Settings{
		Name:        "DiditAPICircuitBreaker",
		MaxRequests: 3, // Allow 3 requests in half-open state
		Interval:    5 * time.Second, // Period to collect data for trip decisions
		Timeout:     10 * time.Second, // Open circuit for 10 seconds
		ReadyToTrip: func(counts gobreaker.Counts) bool {
			return counts.ConsecutiveFailures > 5 // Trip after 5 consecutive failures
		},
		OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
			fmt.Printf("Circuit Breaker '%s' changed from %s to %s\n", name, from, to)
		},
	}
	cb = gobreaker.NewCircuitBreaker(st)
}

func callDiditAPIWithCircuitBreaker(url string) ([]byte, error) {
	body, err := cb.Execute(func() (interface{}, error) {
		resp, err := http.Get(url)
		if err != nil {
			return nil, err // Network error
		}
		defer resp.Body.Close()

		if resp.StatusCode != http.StatusOK {
			// Only count 5xx and 429 as failures for circuit breaker
			if resp.StatusCode == http.StatusTooManyRequests || resp.StatusCode >= http.StatusInternalServerError {
				return nil, fmt.Errorf("API returned status %d", resp.StatusCode)
			}
			// For other 4xx errors, we might not want to trip the breaker, but still return an error
			bodyBytes, _ := ioutil.ReadAll(resp.Body)
			return nil, fmt.Errorf("non-retryable API error: %d %s, response: %s", resp.StatusCode, resp.Status, string(bodyBytes))
		}

		return ioutil.ReadAll(resp.Body)
	})

	if err != nil {
		if errors.Is(err, gobreaker.ErrOpenState) {
			return nil, fmt.Errorf("circuit breaker is open: %w", err)
		}
		return nil, err
	}

	return body.([]byte), nil
}

func main() {
	// Example usage
	apiURL := "https://verification.didit.me/health"
	for i := 0; i < 10; i++ {
		data, err := callDiditAPIWithCircuitBreaker(apiURL)
		if err != nil {
			fmt.Printf("Call %d failed: %v\n", i+1, err)
		} else {
			fmt.Printf("Call %d successful: %s\n", i+1, string(data))
		}
		time.Sleep(1 * time.Second)
	}
}

Die Kombination von Circuit Breakern mit exponentiellem Backoff stellt sicher, dass Ihre Anwendung reaktionsfähig bleibt und einen überlasteten externen Dienst nicht weiter überfordert. Dies ist besonders wichtig bei der Bearbeitung großer Mengen von Identitätsprüfungsanfragen, wie sie bei Didits ID-Verifizierung oder passiven und aktiven Liveness-Checks auftreten.

Umgang mit Webhook-Fehlern und asynchronen Ergebnissen

Die Didit API liefert Ergebnisse oft asynchron über Webhooks, zum Beispiel nachdem ein Benutzer einen ID-Verifizierungsprozess abgeschlossen hat oder wenn eine AML-Screening-Prüfung beendet ist. Ihr Webhook-Endpunkt muss robust sein. Wenn Ihr Endpunkt einen Webhook nicht verarbeiten kann (z. B. einen 5xx-Statuscode zurückgibt), versucht Didit erneut, den Webhook zuzustellen. Es ist entscheidend, dass Sie:

• Empfang sofort bestätigen: Geben Sie so schnell wie möglich einen 2xx-Statuscode zurück, um den erfolgreichen Empfang zu signalisieren, auch wenn die Verarbeitung länger dauert.
• Asynchron verarbeiten: Übergeben Sie die Webhook-Payload an einen Hintergrund-Worker oder eine Message Queue (z. B. Kafka, RabbitMQ) zur Verarbeitung. Dies verhindert, dass Ihr Webhook-Endpunkt die Wiederholungen von Didit überlastet.
• Idempotenz: Stellen Sie sicher, dass Ihre Webhook-Verarbeitungslogik idempotent ist. Wenn Didit den gleichen Webhook mehrmals erneut versucht und zustellt, sollte Ihr System ihn nur einmal verarbeiten, um doppelte Aktionen oder Dateninkonsistenzen zu vermeiden.
• Signaturen überprüfen: Überprüfen Sie immer die Webhook-Signatur mit Ihrem Webhook Secret Key aus der Didit Console, um sicherzustellen, dass die Anfrage tatsächlich von Didit stammt und nicht manipuliert wurde.

Wie Didit hilft

Didit wurde unter Berücksichtigung der Entwicklererfahrung und Zuverlässigkeit entwickelt und bietet Funktionen, die die erweiterte Fehlerbehandlung und Wiederholungsstrategien für Ihre Go-Integrationen von Natur aus vereinfachen. Unser entwicklerfreundlicher Ansatz bedeutet klare, umfassende API-Dokumentation, eine sofortige Sandbox und saubere APIs, die die Integration unkompliziert machen.

• Vorhersehbare Ratenbegrenzung: Didit definiert klar globale und endpunktspezifische Ratenbegrenzungen sowie Standard-HTTP-Header (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After), um Ihre clientseitige Drosselungs- und Backoff-Logik zu steuern. Diese Transparenz ermöglicht es Ihnen, optimierte Wiederholungsmechanismen für Dienste wie ID-Verifizierung und AML-Screening zu entwickeln.
• Modulare Architektur: Unsere modularen Identitäts-Primitive ermöglichen es Ihnen, Workflows aufzubauen, die von Natur aus widerstandsfähig sind. Wenn eine bestimmte Prüfung (z. B. Adressnachweis) ein vorübergehendes Problem aufweist, kann Ihr gesamter Workflow so konfiguriert werden, dass er sich anpasst oder bestimmte Komponenten erneut versucht, ohne nicht verwandte Verifizierungsschritte zu beeinträchtigen.
• KI-native Zuverlässigkeit: Didits KI-natives Backend ist auf Skalierbarkeit und Widerstandsfähigkeit ausgelegt, wodurch die serverseitigen Fehler, denen Sie begegnen, minimiert werden. Dies ermöglicht es Ihnen, Ihre Fehlerbehandlung auf Netzwerk- und clientseitige Probleme zu konzentrieren, anstatt auf ständige Dienstausfälle.
• Kostenloses Core KYC & flexible Preisgestaltung: Starten Sie mit Didits kostenlosem Tarif für Core KYC, um Ihre Fehlerbehandlungs- und Wiederholungsstrategien in einer produktionsähnlichen Umgebung ohne Vorabkosten gründlich zu testen. Unser Pay-per-erfolgreiche-Prüfung-Modell stimmt unseren Erfolg zusätzlich mit Ihrem ab.

Bereit zum Start?

Möchten Sie Didit in Aktion sehen? Fordern Sie noch heute eine kostenlose Demo an.

Beginnen Sie mit der kostenlosen Identitätsprüfung mit Didits kostenlosem Tarif.