Menguasai Pembatasan Tingkat Sisi Klien untuk Integrasi API Didit (ID)

Pembatasan Proaktif adalah KunciTerapkan pembatasan sisi klien ketika X-RateLimit-Remaining turun di bawah 15% untuk menghindari kesalahan 429 dan memastikan ketersediaan layanan yang berkelanjutan.

Exponential Backoff untuk 429sSelalu gunakan strategi exponential backoff (misalnya, 5s, 10s, 20s) saat mencoba kembali permintaan setelah menerima respons 429, mencegah pelanggaran batas tingkat lebih lanjut.

Manfaatkan Header DiditHeader X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset yang disediakan oleh API Didit sangat penting untuk pembatasan tingkat sisi klien yang dinamis dan cerdas.

Didit Menyederhanakan IntegrasiSDK Didit dan pendekatan yang mengutamakan pengembang menyederhanakan implementasi praktik terbaik untuk integrasi API, termasuk mekanisme bawaan dan panduan untuk menangani batas tingkat secara efektif.

Memahami Batas Tingkat API dan Pentingnya

Batas tingkat API adalah aspek fundamental dari layanan web modern, yang dirancang untuk melindungi infrastruktur dari penyalahgunaan, memastikan penggunaan yang adil, dan menjaga stabilitas untuk semua pengguna. Bagi pengembang yang berintegrasi dengan layanan penting seperti platform verifikasi identitas, memahami dan menghormati batas ini sangat penting. Saat berintegrasi dengan API Didit, Anda akan menemukan batas tingkat spesifik yang dirancang untuk memastikan operasi verifikasi identitas yang andal dan berkinerja tinggi.

Didit menerapkan beberapa lapisan pembatasan tingkat, termasuk batas global untuk GET (300 permintaan per menit per aplikasi) dan endpoint Tulis/Hapus (300 permintaan per menit per aplikasi), serta batas spesifik endpoint yang lebih ketat untuk operasi berdampak tinggi. Misalnya, POST /v2/session/ (untuk membuat alur kerja verifikasi) memiliki batas 600 rpm, sementara GET /v2/session//decision/ (untuk mengambil keputusan sesi) dan GET /session//generate-pdf/ dibatasi pada 100 rpm karena intensitas komputasinya.

Melebihi batas ini menghasilkan kode status HTTP 429 (Terlalu Banyak Permintaan). Meskipun ini adalah perlindungan sisi server, pembatasan tingkat sisi klien yang efektif sangat penting untuk mencegah aplikasi Anda mencapai batas ini, memastikan pengalaman pengguna yang lancar dan layanan tanpa gangguan. Kegagalan dalam menerapkan penanganan sisi klien yang tepat dapat menyebabkan kinerja yang menurun, verifikasi yang gagal, dan kesan yang buruk bagi pengguna Anda.

Strategi untuk Pembatasan Tingkat Sisi Klien di JavaScript/TypeScript

Menerapkan pembatasan tingkat sisi klien melibatkan antisipasi dan respons terhadap batas API sebelum diberlakukan oleh server. Ini memerlukan kombinasi pembatasan proaktif dan penanganan kesalahan reaktif. Berikut adalah strategi utamanya:

1. Pembatasan Proaktif dengan Header Batas Tingkat

API Didit menyertakan header spesifik dalam respons 429 yang sangat berharga untuk pembatasan tingkat sisi klien: X-RateLimit-Limit, X-RateLimit-Remaining, dan X-RateLimit-Reset (dalam detik epoch). Anda harus mengurai header ini dan menggunakannya untuk menginformasikan perilaku permintaan klien Anda.

Klien yang kuat akan:

• Memantau X-RateLimit-Remaining: Secara aktif melacak permintaan yang tersisa. Ketika nilai ini turun di bawah ambang batas tertentu (misalnya, 15% dari X-RateLimit-Limit), klien Anda harus mulai mengantre permintaan atau memperlambat laju transmisinya.
• Memanfaatkan X-RateLimit-Reset: Header ini memberi tahu Anda kapan jendela batas tingkat saat ini diatur ulang. Anda dapat menggunakan stempel waktu ini untuk menjadwalkan kapan klien Anda dapat dengan aman melanjutkan permintaan dengan kecepatan penuh.

interface RateLimitHeaders {
  limit: number;
  remaining: number;
  reset: number; // epoch seconds
}

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // Dalam aplikasi nyata, Anda akan mengelola ini secara global atau per-endpoint
  let currentRateLimit: RateLimitHeaders | null = null;

  // Terapkan antrean lokal atau mekanisme penundaan berdasarkan currentRateLimit
  // Untuk kesederhanaan, contoh ini berfokus pada penanganan respons.

  const response = await fetch(url, options);

  const limit = response.headers.get('X-RateLimit-Limit');
  const remaining = response.headers.get('X-RateLimit-Remaining');
  const reset = response.headers.get('X-RateLimit-Reset');

  if (limit && remaining && reset) {
    currentRateLimit = {
      limit: parseInt(limit, 10),
      remaining: parseInt(remaining, 10),
      reset: parseInt(reset, 10),
    };
    console.log(`Batas Tingkat: ${currentRateLimit.remaining}/${currentRateLimit.limit} permintaan tersisa. Diatur ulang pada ${new Date(currentRateLimit.reset * 1000).toLocaleTimeString()}.`);
  }

  return response;
}

2. Menerapkan Exponential Backoff untuk Respons 429

Ketika klien Anda menerima respons 429, pendekatan yang benar bukanlah segera mencoba kembali. Sebaliknya, terapkan strategi exponential backoff. Ini melibatkan penantian untuk periode yang semakin lama di antara percobaan ulang, mengurangi beban pada server dan meningkatkan peluang keberhasilan pada percobaan berikutnya. Respons 429 Didit juga menyertakan header Retry-After, yang menyediakan durasi spesifik (dalam detik) untuk menunggu sebelum mencoba kembali. Selalu prioritaskan header ini jika ada.

async function makeDiditRequestWithRetry(url: string, options: RequestInit, retries = 0): Promise<Response> {
  try {
    const response = await makeDiditRequest(url, options);

    if (response.status === 429) {
      const retryAfter = response.headers.get('Retry-After');
      const delay = retryAfter ? parseInt(retryAfter, 10) * 1000 : Math.pow(2, retries) * 1000; // Exponential backoff: 1s, 2s, 4s...
      console.warn(`Batas tingkat tercapai. Mencoba kembali dalam ${delay / 1000} detik...`);
      await new Promise(resolve => setTimeout(resolve, delay));
      return makeDiditRequestWithRetry(url, options, retries + 1);
    }

    if (!response.ok) {
      throw new Error(`Kesalahan HTTP! status: ${response.status}`);
    }

    return response;
  } catch (error) {
    console.error('Permintaan gagal:', error);
    throw error;
  }
}

// Contoh penggunaan untuk pengambilan keputusan sesi Didit
// Endpoint ini dibatasi hingga 100 rpm.
// makeDiditRequestWithRetry(`/v2/session/${sessionId}/decision/`, { method: 'GET' });

3. Memanfaatkan SDK Didit untuk Integrasi yang Efisien

Didit menawarkan SDK yang kuat untuk berbagai lingkungan, termasuk JavaScript SDK untuk aplikasi web. SDK ini sering kali mengabstraksi sebagian besar kompleksitas interaksi API, termasuk menangani pola kesalahan umum dan menyediakan panggilan balik berbasis peristiwa untuk alur verifikasi. Meskipun logika pembatasan tingkat eksplisit mungkin masih diperlukan untuk panggilan API kustom bervolume tinggi, menggunakan SDK untuk alur verifikasi yang menghadap pengguna (seperti Verifikasi ID, Liveness Pasif & Aktif, atau Estimasi Usia) secara signifikan menyederhanakan integrasi.

SDK dirancang untuk alur kerja yang menghadap pengguna, di mana backend Anda memulai sesi (POST /v2/session/) dan frontend Anda merender UI verifikasi. SDK menangani interaksi dengan layanan Didit, mengurangi beban langsung dalam mengelola batas tingkat panggilan API individual dari sisi klien selama proses verifikasi itu sendiri. Saat berintegrasi dengan JavaScript SDK, Anda menginisialisasinya dengan token sesi dari backend Anda, dan SDK mengelola alur, menyediakan panggilan balik onSuccess, onError, dan onCancel.

Bagaimana Didit Membantu

Didit dirancang untuk menjadi platform identitas yang mengutamakan pengembang, berbasis AI, yang menyediakan opsi integrasi yang fleksibel sambil mempertahankan kinerja yang kuat. Pendekatan kami terhadap desain API dan SDK secara inheren membantu dalam mengelola batas tingkat dan memastikan operasi yang lancar:

• Dokumentasi Batas Tingkat yang Jelas: Didit menyediakan dokumentasi yang transparan dan terperinci tentang semua batas tingkat API, memungkinkan pengembang merencanakan integrasi mereka secara efektif.
• Header Informatif: Penyertaan header X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, dan Retry-After memberdayakan pengembang untuk membangun aplikasi klien yang cerdas dan mengatur diri sendiri.
• Arsitektur Modular: Desain modular Didit berarti Anda hanya mengintegrasikan primitif identitas yang Anda butuhkan, seperti Verifikasi ID untuk pemeriksaan dokumen, Liveness Pasif & Aktif untuk deteksi penipuan, atau Estimasi Usia untuk verifikasi usia. Pendekatan yang ditargetkan ini dapat membantu mengoptimalkan pola panggilan API Anda.
• SDK untuk Alur Kerja yang Disederhanakan: SDK web dan seluler kami menyederhanakan integrasi proses verifikasi yang kompleks yang menghadap pengguna. Dengan menangani seluk-beluk alur verifikasi, termasuk banyak panggilan API yang mendasarinya, SDK mengabstraksi masalah batas tingkat langsung untuk interaksi spesifik tersebut, memungkinkan Anda untuk fokus pada logika aplikasi Anda.
• KYC Inti Gratis: Didit menawarkan KYC Inti Gratis, memungkinkan bisnis untuk memulai layanan verifikasi identitas penting tanpa biaya di muka, sehingga lebih mudah untuk menguji dan mengoptimalkan strategi integrasi Anda, termasuk penanganan batas tingkat.

Siap untuk Memulai?

Siap melihat Didit beraksi? Dapatkan demo gratis hari ini.

Mulai verifikasi identitas secara gratis dengan tingkat gratis Didit.