Hastighetsgrenser

Chastify begrenser trafikken til utvidelsens API for å beskytte låseøkter, lagring, enheter og varslingssystemer.

Hastighetsgrenser gjelder for både iframe-brotrafikk som rutes gjennom Chastify og backend-kall gjort med Developer API-nøkler.

Gjeldende utvidelsesbøtter

Bøtte	Grense	Typiske endepunkter
Les	300/min	session.get, state.get, metadata.get, fillesninger, status for vanlig handling
Skriv	120/min	Skriving av backend-tilstand, oppdateringer av metadata, konfigurasjon med vanlige handlinger, opprettelse av serververifisert kjøring
Last opp	10/min	Opplastinger av kjøretids- og oppsettfiler
Handling	30/min	Låsehandlinger, enhetskommandoer, tilpassede logger, tilpassede varsler, serververifisert resultatoppgjør
Token	30/min	Oppstart av iframe-økt/generering av autentiseringstoken

Grensene evalueres over et vindu på ett minutt.

note

Dette er plattformstandardene. Chastify-administratorer/nettstedseiere kan konfigurere overstyringer per utvidelse for offisielle utvidelser eller utvidelser med uvanlig høyt volum. Overstyringer lagres i konfigurasjonen for utvidelsesappen og bufres kort i Redis for raskt oppslag av forespørselsstier.

info

Opplastings- og handlingsbøttene er bevisst strammere enn lese-/tilstandsbøttene. Opplastinger bruker lagringsplass og båndbredde. Handlinger kan påvirke låsestatus, enheter, varsler og brukersynlig historikk.

Hvordan nøkler telles

Hastighetsbegrensningsnøkler inkluderer:

• autentisert Chastify bruker-ID når førstepartsgrensesnittet kaller et endepunkt
• Nøkkel-ID for utvikler-API når backend-enheten din kaller endepunkter for utvidelsesøkt
• IP-adresse for anonyme eller uautoriserte stier
• målet sessionId eller lockId når tilgjengelig

Dette betyr at én støyende utvidelsesøkt ikke bør forbruke hele det globale utvidelses-API-budsjettet.

Anbefalt klientatferd

Iframe-en eller backend-en din bør behandle 429 Too Many Requests som en normal betingelse for at den kan prøves på nytt.

Bruk eksponentiell tilbaketrekking for gjentatte feil:

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

Veiledning for iframe-broen

For iframe-broklienter:

• Bufre session.get-resultater for sidens levetid med mindre du trenger nye låsedata.
• Lagre midlertidige endringer i brukergrensesnittet lokalt og send pålitelige endringer til backend-en din.
• Unngå raske avlesningsløkker. Foretrekk brukerutløste lesninger eller langsomme oppdateringsintervaller.

Eksempel på debounced backend-lagring:

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

Veiledning for backend-utvidelser

For backend-kall med en Developer API-nøkkel:

• Hold privilegerte handlinger serververifiserte og brukerutløste.
• Bruk PUT/PATCH /api/extensions/sessions/:sessionId/state kun fra backend-en din med Developer API-legitimasjon.
• Ikke prøv å låse handlinger på nytt i blinde hvis det første forsøket kan ha vært vellykket.
• Gjør spill-/utfordringsavgjørelse idempotent med en løps-ID.
• Last opp filer bare når brukeren eksplisitt sender inn en fil.
• Lagre dine egne eksterne poster hvis du trenger høyerefrekvent telemetri.

warning

Aldri øk handlingsgrensene for å kompensere for ubekreftede nettleserkall. Nettleserens iframe-kode er ikke klarert. Sensitive mutasjoner bør valideres av backend-en din før du kaller Chastify.

Hvilken bøtte bør jeg forvente?

Vanlige eksempler:

• GET /api/extensions/sessions/:sessionId bruker lesebøtta.
• GET /api/extensions/sessions/:sessionId/state bruker lesebøtta.
• PUT/PATCH /api/extensions/sessions/:sessionId/state bruker skrivebøtta.
• POST /api/extensions/sessions/:sessionId/files bruker opplastingsbøtta.
• POST /api/extensions/sessions/:sessionId/action bruker handlingsbøtten.
• POST /api/extensions/sessions/:sessionId/device-command bruker handlingsbøtten.
• POST /api/extensions/sessions/:sessionId/logs/custom bruker handlingsbøtten.
• POST /api/extensions/sessions/:sessionId/notifications/custom bruker handlingsbøtten.
• GET /api/extensions/sessions/:sessionId/auth bruker token-bøtten.

Fremtidens granulære bøtter

De nåværende kategoriene er brede. Chastify kan dele dem ytterligere opp etter hvert som utvikler-API-et vokser, for eksempel:

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

Grensene per utvidelse kan økes av Chastify-administratorer/nettstedseiere når en offisiell eller godkjent utvidelse med høyt volum har et legitimt behov. Design klienter slik at 429-håndteringen er generisk og ikke avhenger av eksakte bøttenavn eller faste plattformstandarder.