Освоение клиентского управления лимитами запросов для интеграции с Didit API (RU)

Активное регулирование — ключ к успехуРеализуйте клиентское регулирование, когда X-RateLimit-Remaining опускается ниже 15%, чтобы избежать ошибок 429 и обеспечить непрерывную доступность сервиса.

Экспоненциальная задержка для ошибок 429Всегда используйте стратегию экспоненциальной задержки (например, 5с, 10с, 20с) при повторных попытках запросов после получения ответа 429, предотвращая дальнейшие превышения лимитов.

Используйте заголовки DiditЗаголовки X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset, предоставляемые API Didit, критически важны для динамического и интеллектуального клиентского ограничения скорости.

Didit упрощает интеграциюSDK Didit и подход, ориентированный на разработчиков, упрощают внедрение лучших практик для интеграции API, включая встроенные механизмы и руководство по эффективной обработке лимитов запросов.

Понимание лимитов API и их важность

Лимиты API являются фундаментальным аспектом современных веб-сервисов, предназначенных для защиты инфраструктуры от злоупотреблений, обеспечения справедливого использования и поддержания стабильности для всех пользователей. Для разработчиков, интегрирующихся с критически важными сервисами, такими как платформы верификации личности, понимание и соблюдение этих лимитов имеет первостепенное значение. При интеграции с API Didit вы столкнетесь с определёнными лимитами запросов, разработанными для обеспечения надёжных и высокопроизводительных операций по верификации личности.

Didit применяет несколько уровней ограничения скорости, включая глобальные лимиты для GET (300 запросов в минуту на приложение) и Write/Delete конечных точек (300 запросов в минуту на приложение), а также более строгие лимиты для высоконагруженных операций, специфичные для конечных точек. Например, POST /v2/session/ (для создания рабочих процессов верификации) имеет лимит 600 запросов в минуту, в то время как GET /v2/session/<id>/decision/ (для получения решений по сессии) и GET /session/<id>/generate-pdf/ ограничены 100 запросами в минуту из-за их вычислительной интенсивности.

Превышение этих лимитов приводит к HTTP-статусу 429 (Слишком много запросов). Хотя это серверная защита, эффективное клиентское ограничение скорости имеет решающее значение для предотвращения достижения этих потолков вашим приложением, обеспечивая плавный пользовательский опыт и бесперебойное обслуживание. Неспособность реализовать надлежащую клиентскую обработку может привести к снижению производительности, неудачным верификациям и плохому впечатлению у ваших пользователей.

Стратегии клиентского ограничения скорости в JavaScript/TypeScript

Реализация клиентского ограничения скорости включает в себя предвидение и реагирование на лимиты API до того, как они будут применены сервером. Это требует сочетания проактивного регулирования и реактивной обработки ошибок. Вот ключевые стратегии:

1. Проактивное регулирование с заголовками Rate Limit

API Didit включает специальные заголовки в ответах 429, которые бесценны для клиентского ограничения скорости: X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset (в секундах эпохи). Вы должны анализировать эти заголовки и использовать их для информирования поведения запросов вашего клиента.

Надёжный клиент будет:

• Мониторить X-RateLimit-Remaining: Активно отслеживать оставшиеся запросы. Когда это значение опускается ниже определённого порога (например, 15% от X-RateLimit-Limit), ваш клиент должен начать ставить запросы в очередь или замедлять скорость их передачи.
• Использовать X-RateLimit-Reset: Этот заголовок сообщает вам, когда текущее окно лимита сбрасывается. Вы можете использовать эту отметку времени, чтобы планировать, когда ваш клиент сможет безопасно возобновить запросы на полной скорости.

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

async function makeDiditRequest(url: string, options: RequestInit): Promise<Response> {
  // В реальном приложении вы будете управлять этим глобально или для каждой конечной точки
  let currentRateLimit: RateLimitHeaders | null = null;

  // Реализуйте локальную очередь или механизм задержки на основе currentRateLimit
  // Для простоты этот пример фокусируется на обработке ответа.

  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(`Rate Limit: ${currentRateLimit.remaining}/${currentRateLimit.limit} requests remaining. Resets at ${new Date(currentRateLimit.reset * 1000).toLocaleTimeString()}.`);
  }

  return response;
}

2. Реализация экспоненциальной задержки для ответов 429

Когда ваш клиент получает ответ 429, правильный подход — немедленно не повторять запрос. Вместо этого реализуйте стратегию экспоненциальной задержки. Это включает ожидание всё более длительных периодов между повторными попытками, снижая нагрузку на сервер и увеличивая вероятность успеха при последующих попытках. Ответы Didit 429 также включают заголовок Retry-After, который предоставляет конкретную продолжительность (в секундах) ожидания перед повторной попыткой. Всегда отдавайте приоритет этому заголовку, если он присутствует.

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; // Экспоненциальная задержка: 1с, 2с, 4с...
      console.warn(`Превышен лимит запросов. Повторная попытка через ${delay / 1000} секунд...`);
      await new Promise(resolve => setTimeout(resolve, delay));
      return makeDiditRequestWithRetry(url, options, retries + 1);
    }

    if (!response.ok) {
      throw new Error(`Ошибка HTTP! статус: ${response.status}`);
    }

    return response;
  } catch (error) {
    console.error('Запрос не удался:', error);
    throw error;
  }
}

// Пример использования для получения решения по сессии Didit
// Эта конечная точка ограничена 100 запросами в минуту.
// makeDiditRequestWithRetry(`/v2/session/${sessionId}/decision/`, { method: 'GET' });

3. Использование SDK Didit для упрощенной интеграции

Didit предлагает надёжные SDK для различных сред, включая JavaScript SDK для веб-приложений. Эти SDK часто абстрагируют большую часть сложности взаимодействия с API, включая обработку общих шаблонов ошибок и предоставление колбэков, управляемых событиями, для потоков верификации. Хотя явная логика ограничения скорости может по-прежнему быть необходимой для высокообъёмных, пользовательских вызовов API, использование SDK для пользовательских потоков верификации (таких как верификация ID, пассивная и активная проверка живости или оценка возраста) значительно упрощает интеграцию.

SDK разработаны для пользовательских рабочих процессов, где ваш бэкенд инициирует сессию (POST /v2/session/), а ваш фронтенд отображает пользовательский интерфейс верификации. SDK обрабатывает взаимодействие с сервисами Didit, снижая прямую нагрузку по управлению индивидуальными лимитами запросов API со стороны клиента во время самого процесса верификации. При интеграции с JavaScript SDK вы инициализируете его токеном сессии с вашего бэкенда, и он управляет потоком, предоставляя колбэки onSuccess, onError и onCancel.

Как Didit помогает

Didit разработан как платформа идентификации, ориентированная на разработчиков и использующая ИИ, которая предоставляет гибкие возможности интеграции при сохранении надёжной производительности. Наш подход к дизайну API и SDK изначально помогает в управлении лимитами запросов и обеспечении бесперебойной работы:

• Чёткая документация по лимитам запросов: Didit предоставляет прозрачную и подробную документацию по всем лимитам запросов API, позволяя разработчикам эффективно планировать свои интеграции.
• Информативные заголовки: Включение заголовков X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset и Retry-After даёт разработчикам возможность создавать интеллектуальные, саморегулирующиеся клиентские приложения.
• Модульная архитектура: Модульная конструкция Didit означает, что вы интегрируете только те примитивы идентификации, которые вам нужны, такие как верификация ID для проверки документов, пассивная и активная проверка живости для обнаружения мошенничества или оценка возраста для верификации возраста. Этот целевой подход может помочь оптимизировать шаблоны вызовов API.
• SDK для упрощенных рабочих процессов: Наши веб- и мобильные SDK упрощают интеграцию сложных пользовательских процессов верификации. Обрабатывая тонкости потока верификации, включая многие базовые вызовы API, SDK абстрагируют прямые проблемы с лимитами запросов для этих конкретных взаимодействий, позволяя вам сосредоточиться на логике вашего приложения.
• Бесплатный Core KYC: Didit предлагает бесплатный Core KYC, позволяя предприятиям начать работу с основными услугами верификации личности без первоначальных затрат, что упрощает тестирование и оптимизацию ваших стратегий интеграции, включая обработку лимитов запросов.

Готовы начать?

Хотите увидеть Didit в действии? Получите бесплатную демонстрацию сегодня.

Начните бесплатно проверять личности с бесплатным тарифом Didit.