Limity szybkości

Chastify rozszerzenie API limitów prędkości ruchu w celu ochrony sesji blokad, pamięci masowej, urządzeń i systemów powiadomień.

Limity przepustowości dotyczą zarówno ruchu mostu iframe kierowanego przez Chastify, jak i wywołań zaplecza wykonywanych przy użyciu kluczy API dla programistów.

Aktualne zestawy rozszerzeń

Wiadro	Limit	Typowe punkty końcowe
Odczyt	300/min	session.get, state.get, metadata.get, odczyt pliku, status zwykłej akcji
Zapis	120/min	Zapis stanu zaplecza, aktualizacje metadanych, konfiguracja zwykłych działań, tworzenie przebiegów zweryfikowanych przez serwer
Prześlij	10/min	Przesłanie plików wykonawczych i instalacyjnych
Akcja	30/min	Akcje blokady, polecenia urządzeń, niestandardowe logi, niestandardowe powiadomienia, rozliczenie wyników zweryfikowanych przez serwer
Token	30/min	Uruchomienie sesji iframe/generowanie tokena uwierzytelniającego

Limity oceniane są w ciągu jednej minuty.

notatka

Oto domyślne ustawienia platformy. Administratorzy/właściciele witryny Chastify mogą konfigurować nadpisania dla poszczególnych rozszerzeń, zarówno dla rozszerzeń oficjalnych, jak i o wyjątkowo dużej liczbie użytkowników. Nadpisania są przechowywane w konfiguracji aplikacji rozszerzenia i na krótko buforowane w Redis w celu szybkiego wyszukiwania ścieżki żądania.

informacja

Kontenery przesyłania i akcji są celowo bardziej zwarte niż kontenery odczytu/stanu. Przesyłanie danych zużywa pamięć masową i przepustowość. Akcje mogą wpływać na stan blokady, urządzenia, powiadomienia i historię widoczną dla użytkownika.

Jak liczone są klucze

Klucze limitów szybkości obejmują:

• uwierzytelniony identyfikator użytkownika Chastify, gdy interfejs użytkownika pierwszej strony wywołuje punkt końcowy
• Identyfikator klucza API dla programistów, gdy zaplecze wywołuje punkty końcowe sesji rozszerzeń
• Adres IP dla ścieżek anonimowych lub nieuwierzytelnionych
• docelowy sessionId lub lockId, jeśli dostępny

Oznacza to, że jedna sesja rozszerzenia powodująca zakłócenia nie powinna zużywać całego globalnego budżetu interfejsu API rozszerzeń.

Zalecane zachowanie klienta

Twoja ramka iframe lub zaplecze powinno traktować 429 Too Many Requests jako normalny warunek możliwy do powtórzenia.

W przypadku powtarzających się błędów zastosuj metodę wycofywania wykładniczego:

async function callWithBackoff<T>(fn: () => Promise<T>, attempts = 4): Promise<T> {
  let delayMs = 500;

  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    try {
      return await fn();
    } catch (error: any) {
      const status = error?.status ?? error?.response?.status;
      if (status !== 429 || attempt === attempts) throw error;

      await new Promise((resolve) => setTimeout(resolve, delayMs));
      delayMs *= 2;
    }
  }

  throw new Error("request_failed");
}

Wskazówki dotyczące mostu iframe

Dla klientów mostu iframe:

• Przechowuj wyniki session.get w pamięci podręcznej przez cały okres istnienia strony, chyba że potrzebujesz nowych danych blokady.
• Przechowuj tymczasowe zmiany interfejsu użytkownika lokalnie i wysyłaj zaufane zmiany do zaplecza.
• Unikaj szybkich pętli odpytywania. Preferuj odczyty inicjowane przez użytkownika lub długie interwały odświeżania.

Przykład nieudanego zapisu back-end:

let saveTimer: number | undefined;

function scheduleStateSave(data: Record<string, unknown>) {
  window.clearTimeout(saveTimer);
  saveTimer = window.setTimeout(() => {
    fetch("/your-extension-backend/state", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(data),
    }).catch(console.error);
  }, 500);
}

Wskazówki dotyczące rozszerzeń zaplecza

W przypadku wywołań zaplecza z kluczem API dla programisty:

• Utrzymuj akcje uprzywilejowane weryfikowane przez serwer i wyzwalane przez użytkownika.
• Używaj PUT/PATCH /api/extensions/sessions/:sessionId/state tylko z poziomu zaplecza, korzystając z danych uwierzytelniających API programisty.
• Nie próbuj ponownie blokować akcji bezmyślnie, jeśli pierwsza próba mogła się powieść.
• Ustaw rozliczenie gry/wyzwania tak, aby było idempotentne z identyfikatorem przebiegu.
• Prześlij pliki tylko wtedy, gdy użytkownik wyraźnie wyrazi na to zgodę.
• Jeśli potrzebujesz danych telemetrycznych o wyższej częstotliwości, przechowuj własne zewnętrzne rekordy.

ostrzeżenie

Nigdy nie zwiększaj limitów akcji, aby zrekompensować niezweryfikowane wywołania przeglądarki. Kod iframe przeglądarki nie jest zaufany. Wrażliwe mutacje powinny zostać zweryfikowane przez system zaplecza przed wywołaniem Chastify.

Którego wiadra mogę się spodziewać?

Typowe przykłady:

• GET /api/extensions/sessions/:sessionId używa kontenera odczytu.
• GET /api/extensions/sessions/:sessionId/state używa kontenera odczytu.
• PUT/PATCH /api/extensions/sessions/:sessionId/state używa kontenera zapisu.
• POST /api/extensions/sessions/:sessionId/files używa kontenera przesyłania.
• POST /api/extensions/sessions/:sessionId/action używa kontenera akcji.
• POST /api/extensions/sessions/:sessionId/device-command używa kontenera akcji.
• POST /api/extensions/sessions/:sessionId/logs/custom używa kontenera akcji.
• POST /api/extensions/sessions/:sessionId/notifications/custom używa kontenera akcji.
• GET /api/extensions/sessions/:sessionId/auth używa kontenera tokenów.

Przyszłe wiadra granulowane

Obecne grupy są szerokie. Chastify może je dalej dzielić w miarę rozwoju API dla programistów, na przykład:

• state.write
• metadata.write
• lock.action
• notifications.custom
• device.command
• files.upload

Limity dla każdego rozszerzenia mogą zostać zwiększone przez administratorów/właścicieli witryny Chastify, gdy oficjalne lub zatwierdzone rozszerzenie o dużej liczbie użytkowników ma uzasadnioną potrzebę. Projektuj klientów tak, aby obsługa 429 była generyczna i nie zależała od dokładnych nazw kontenerów ani stałych domyślnych ustawień platformy.