المدونة · 6 مارس 2026

إتقان معالجة الأخطاء وإعادة المحاولة في Didit API باستخدام Go (AR)

يتطلب بناء تكاملات قوية مع Didit API في Go استراتيجيات متطورة لمعالجة الأخطاء وإعادة المحاولة. يستكشف هذا الدليل أفضل الممارسات، بدءًا من فهم حدود معدل Didit ورموز الأخطاء المحددة.

بواسطة Didit6 مارس 2026تحديث 21 مايو 2026

فهم حدود معدل Diditقم بتطبيق تقييد من جانب العميل وتراجع أسي لاستجابات 429، مع الاستفادة من رؤوس X-RateLimit-Limit و X-RateLimit-Remaining و X-RateLimit-Reset لمنع انقطاع الخدمة.

تمييز أنواع الأخطاءميز بين الأخطاء العابرة (مثل مشاكل الشبكة، عدم توفر الخدمة) والأخطاء الدائمة (مثل مفاتيح API غير الصالحة، الطلبات المشوهة) لتطبيق منطق إعادة المحاولة المناسب أو الفشل السريع.

تطبيق آليات إعادة محاولة قويةاستخدم حلقات إعادة محاولة منظمة مع تراجع أسي، واضطراب، ومحاولات إعادة محاولة قصوى للتعامل مع الإخفاقات العابرة بمرونة، مما يحسن موثوقية العمليات الحرجة مثل إنشاء الجلسات.

أسلوب Didit الذي يركز على المطورين يبسط التكاملتوفر Didit وثائق API واضحة، ورؤوسًا محددة لتحديد المعدل، وبنية معيارية، مما يمكّن مطوري Go من بناء تدفقات تحقق هوية مرنة بسهولة وثقة.

يعد دمج واجهات برمجة التطبيقات (APIs) للجهات الخارجية حجر الزاوية في تطوير التطبيقات الحديثة، ولا يختلف التحقق من الهوية عن ذلك. عند العمل مع خدمات حيوية مثل منصة هوية Didit، فإن ضمان مرونة تكاملك أمام تقلبات الشبكة، واضطرابات الخدمة، وحدود المعدل أمر بالغ الأهمية. يتعمق هذا الدليل في استراتيجيات متقدمة لمعالجة الأخطاء وإعادة المحاولة مصممة خصيصًا لتكاملات Didit API باستخدام Go، مما يساعدك على بناء أنظمة قوية وموثوقة.

فهم بيئة أخطاء Didit API

قبل تطبيق أي منطق لإعادة المحاولة، من الضروري فهم أنواع الأخطاء التي قد تواجهها. Didit API، مثل العديد من الخدمات المصممة جيدًا، تتواصل مع حالات مختلفة عبر رموز حالة HTTP. بينما تشير رموز 2xx القياسية إلى النجاح، ستركز بشكل أساسي على 4xx (أخطاء العميل) و 5xx (أخطاء الخادم)، وخاصة 429 (طلبات كثيرة جدًا).

تحديد معدل Didit وما يعنيه لك

تفرض Didit تحديد المعدل للحفاظ على استقرار API. هذا جانب حاسم يجب إدارته في تكاملك. على سبيل المثال، عادةً ما تحتوي نقاط نهاية GET على حد عالمي يبلغ 300 طلب في الدقيقة لكل تطبيق، مع وجود نقاط نهاية محددة مثل session-decision (100 طلب في الدقيقة) أو session-v2-create (600 طلب في الدقيقة) لها حدودها الخاصة، وربما تكون أكثر صرامة. عندما تصل إلى حد المعدل، تستجيب Didit برمز حالة 429 Too Many Requests وتتضمن رؤوسًا مفيدة:

X-RateLimit-Limit: الحد الأقصى لعدد الطلبات المسموح بها في النافذة الحالية.
X-RateLimit-Remaining: عدد الطلبات المتبقية في النافذة الحالية.
X-RateLimit-Reset: الوقت (بالثواني الإيبوخية) الذي يتم فيه إعادة تعيين نافذة حد المعدل الحالية.
Retry-After: (غالبًا ما يتم تضمينه) عدد الثواني للانتظار قبل إجراء طلب آخر.

يجب أن يراقب عميل Go هذه الرؤوس بنشاط. عندما ينخفض X-RateLimit-Remaining إلى ما دون عتبة معينة (على سبيل المثال، 15% من X-RateLimit-Limit)، يجب عليك تقييد طلباتك بشكل استباقي. يمكن أن يؤدي تجاهل هذه الرؤوس إلى أخطاء 429 مستمرة، مما يؤثر على قدرة تطبيقك على إنشاء جلسات تحقق أو استرداد النتائج من منتجات مثل Didit's ID Verification أو AML Screening.

تطبيق استراتيجيات إعادة محاولة قوية مع التراجع الأسي في Go

بالنسبة للأخطاء العابرة (مثل مهلات الشبكة، أو عدم توفر الخدمة مؤقتًا، أو 429s)، تعد عمليات إعادة المحاولة ضرورية. ومع ذلك، يمكن أن تؤدي عمليات إعادة المحاولة الساذجة إلى تفاقم المشاكل. المعيار الذهبي هو التراجع الأسي مع الاضطراب.

التراجع الأسي مع الاضطراب

يعني التراجع الأسي زيادة وقت الانتظار بين عمليات إعادة المحاولة بشكل أسي. يمنع الاضطراب (إضافة تأخير عشوائي صغير) مشكلة 'القطيع الصاخب' حيث يقوم العديد من العملاء بإعادة المحاولة في وقت واحد بعد انقطاع، مما يغرق الخدمة مرة أخرى. إليك مثال مفاهيمي في Go:

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))
	}
}

يوضح هذا المقتطف كيفية التعامل مع أخطاء الشبكة، و 429s (مع احترام Retry-After)، وأخطاء 5xx الشائعة مع التراجع الأسي والاضطراب. كما يوضح الفشل السريع لأخطاء 4xx غير القابلة لإعادة المحاولة، والتي عادة ما تكون بسبب إدخال غير صحيح ولن يتم حلها عند إعادة المحاولة. هذا أمر بالغ الأهمية لعمليات مثل إنشاء جلسة تحقق باستخدام بنية Didit المعيارية.

تطبيق نمط قاطع الدائرة

بينما تساعد عمليات إعادة المحاولة في حل المشكلات العابرة، فإن إعادة المحاولة المستمرة لخدمة فاشلة يمكن أن تزيد من إجهادها أو تضيع الموارد إذا كانت الخدمة معطلة بالفعل. وهنا يأتي دور نمط قاطع الدائرة. يراقب قاطع الدائرة حالات الفشل، وإذا وصلت إلى عتبة معينة، فإنه 'يفتح' الدائرة، مما يمنع المزيد من الطلبات لفترة محددة. بعد هذه الفترة، يسمح ببعض الطلبات الاختبارية لمعرفة ما إذا كانت الخدمة قد تعافت.

في Go، يمكنك استخدام مكتبات مثل sony/gobreaker لتطبيق هذا النمط:

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)
	}
}

يضمن الجمع بين قواطع الدائرة والتراجع الأسي أن يظل تطبيقك مستجيبًا ولا يغرق خدمة خارجية تكافح. هذا مهم بشكل خاص عند التعامل مع طلبات التحقق من الهوية عالية الحجم، مثل تلك التي تتضمن Didit's ID Verification أو Passive & Active Liveness checks.

التعامل مع إخفاقات Webhook والنتائج غير المتزامنة

غالبًا ما يوفر Didit API نتائج غير متزامنة عبر webhooks، على سبيل المثال، بعد أن يكمل المستخدم تدفق التحقق من الهوية أو عند الانتهاء من فحص AML Screening. يجب أن تكون نقطة نهاية webhook الخاصة بك قوية. إذا فشلت نقطة النهاية الخاصة بك في معالجة webhook (على سبيل المثال، أرجعت رمز حالة 5xx)، فستقوم Didit بإعادة محاولة تسليم webhook. من الضروري:

الإقرار بالاستلام فورًا: أرجع رمز حالة 2xx في أسرع وقت ممكن للإشارة إلى الاستلام الناجح، حتى لو استغرقت المعالجة وقتًا أطول.
المعالجة غير المتزامنة: سلم حمولة webhook إلى عامل خلفية أو قائمة انتظار رسائل (مثل Kafka، RabbitMQ) للمعالجة. هذا يمنع نقطة نهاية webhook الخاصة بك من تجاوز مهلة إعادة محاولة Didit.
اللا تكرارية: تأكد من أن منطق معالجة webhook الخاص بك لا تكراري. إذا قامت Didit بإعادة المحاولة وتسليم نفس webhook عدة مرات، يجب أن يقوم نظامك بمعالجته مرة واحدة فقط لتجنب الإجراءات المكررة أو عدم اتساق البيانات.
التحقق من التوقيعات: تحقق دائمًا من توقيع webhook باستخدام Webhook Secret Key الخاص بك من Didit Console للتأكد من أن الطلب نشأ بالفعل من Didit ولم يتم التلاعب به.

كيف تساعد Didit

تم تصميم Didit مع وضع تجربة المطور والموثوقية في الاعتبار، حيث توفر ميزات تبسط بطبيعتها معالجة الأخطاء المتقدمة واستراتيجيات إعادة المحاولة لتكاملات Go الخاصة بك. يعني نهجنا الذي يركز على المطورين وثائق API واضحة وشاملة، وبيئة اختبار فورية، وواجهات برمجة تطبيقات نظيفة تجعل التكامل مباشرًا.

تحديد معدل متوقع: تحدد Didit بوضوح حدود المعدل العالمية والخاصة بنقطة النهاية، جنبًا إلى جنب مع رؤوس HTTP القياسية (X-RateLimit-Limit، X-RateLimit-Remaining، X-RateLimit-Reset، Retry-After) لتوجيه تقييد العميل ومنطق التراجع. تمنحك هذه الشفافية القدرة على بناء آليات إعادة محاولة محسّنة لخدمات مثل ID Verification و AML Screening.
بنية معيارية: تعني أصول هويتنا المعيارية أنه يمكنك بناء سير عمل مرن بطبيعته. إذا واجه فحص معين (مثل إثبات العنوان) مشكلة عابرة، يمكن تكوين سير العمل العام الخاص بك للتكيف أو إعادة محاولة مكونات محددة دون التأثير على خطوات التحقق غير ذات الصلة.
موثوقية مدعومة بالذكاء الاصطناعي: تم تصميم خلفية Didit المدعومة بالذكاء الاصطناعي من أجل التوسع والمرونة، مما يقلل من أخطاء الخادم التي ستواجهها. يتيح لك ذلك التركيز على معالجة أخطاء الشبكة والعميل، بدلاً من انقطاعات الخدمة المستمرة.
معرفة العميل الأساسية المجانية والتسعير المرن: ابدأ مع الطبقة المجانية من Didit لمعرفة العميل الأساسية، مما يتيح لك اختبار معالجة الأخطاء واستراتيجيات إعادة المحاولة بدقة في بيئة شبيهة بالإنتاج دون تكاليف أولية. يتوافق نموذج الدفع لكل فحص ناجح لدينا بشكل أكبر مع نجاحنا مع نجاحك.

هل أنت جاهز للبدء؟

هل أنت جاهز لرؤية Didit في العمل؟ احصل على عرض توضيحي مجاني اليوم.

ابدأ في التحقق من الهويات مجانًا مع الطبقة المجانية من Didit.