Ratenbegrenzung

Es gibt heute keine erzwungene Ratenbegrenzung pro Schlüssel. Senden Sie, was der tatsächliche Gästeverkehr Ihrer Location braucht – schreiben Sie keine Retry-Logik für ein 429, das die API derzeit gar nicht senden kann.

Das bleibt nicht für immer so, und das verschweigen wir nicht: Ein Limit kommt, zugeschnitten auf die Zahlen dieser Seite. Es wird vorab angekündigt, nie stillschweigend aktiviert, und dann auf die übliche Art signalisiert – 429 Too Many Requests mit einem Retry-After-Header. Ein API-Schlüssel ist der natürliche Zähler dafür: Sie senden ihn ohnehin bei jedem Aufruf, und jeder Schlüssel gehört zu genau einer Location (bei einem geheimen Schlüssel meist zu einer einzigen Serverintegration) – ein Limit pro Schlüssel ist ein Limit pro echtem Aufrufer, nicht pro URL oder IP. (Die eine Ausnahme ist BookDinePlays eigener plattformweiter geheimer Schlüssel, der bewusst an keine einzelne Location gebunden ist und den öffentlichen Datenverkehr aller Locations hinter einem Credential bündelt – keine externe Integration erhält je einen, das ändert also nichts an dem, was unten folgt.)

Worauf Sie planen sollten

Diese Zahlen legen wir fest, Sie müssen sie nicht raten – hier die Herleitung. Die gesamte Sitzung eines Gasts – Seite laden, ein paar Termine prüfen, buchen – sieht so aus:

Zusammengezählt bleibt die Sitzung eines Gasts bequem unter 30 Aufrufen, die meisten davon in den ersten Sekunden. Ein veröffentlichbarer Schlüssel wird von allen Gästen auf der Website der Location gleichzeitig genutzt – bemessen Sie Ihre Obergrenze also für mehrere gleichzeitig eintreffende Gäste, nicht für einen einzelnen: Ein Dutzend Gäste, die zum Freitagabend-Anpfiff gemeinsam die Seite öffnen, sind grob 12 × (6 Seitenaufruf + 14 Vorabladen) ≈ 240 Aufrufe in diesen ersten Sekunden, noch bevor eine ihrer Buchungen überhaupt beginnt.

Planen Sie mit 300 Anfragen pro Schlüssel und Minute – und lassen Sie dieses Budget so anfallen, wie der Gästeverkehr tatsächlich eintrifft, statt es gleichmäßig über die Minute zu verteilen: Bis zu den vollen 300 dürfen in jedem 10-Sekunden-Fenster anfallen, was die 240 Aufrufe des Anpfiffs oben bequem mit Reserve abdeckt. Das ist eine Obergrenze, nicht zwei konkurrierende – ein Schub ist dasselbe Minutenbudget, nur schnell ausgegeben, keine zusätzliche Erlaubnis obendrauf: 240 Aufrufe in den ersten zehn Sekunden, gefolgt von ruhigerem Buchungsverkehr für den Rest der Minute, zehren beide vom selben Budget von 300. Das deckt eine geschäftige Sportsbar mit einem Dutzend gleichzeitig stöbernder und buchender Gäste auf einem veröffentlichbaren Schlüssel ab; ein geheimer Schlüssel für eine einzelne Serverintegration kommt kaum in die Nähe. Liegt Ihre Integration regelmäßig in dessen Nähe, steckt meist eine Retry-Schleife oder bei jedem Tastendruck neu geladene Öffnungszeiten dahinter, kein echter Gästeverkehr – die Verhaltensregeln unten beheben beides.

Wenn Sie heute schon darüber liegen

Ein Client, der heute schon deutlich über diesen Zahlen liegt – kein Schub, sondern ein dauerhaftes Muster, etwa die Verfügbarkeit den ganzen Tag im Sekundentakt abzufragen – bekommt eine menschliche Antwort, keine stille Blockade: Wir melden uns zuerst, um zu verstehen, was Sie bauen, bevor sich etwas ändert. Wissen Sie schon jetzt, dass Sie mehr brauchen – Sie bündeln zum Beispiel mehrere Locations hinter einem Schlüssel oder bauen etwas, das dauerhaft abfragt –, sagen Sie es uns vorher unter hello@bookdineplay.com, statt es erst zu merken, wenn ein Limit existiert.

Gutes Client-Verhalten

Vier Gewohnheiten halten jede Integration bequem innerhalb der Zahlen oben, Limit hin oder her:

• Verfügbarkeit entprellen. Auslösen nach der Pause, nicht bei jedem Tastendruck oder Reglertick. 300 ms, nachdem ein Gast aufhört, Gruppengröße, Datum oder Ressourcentyp zu ändern, ist ein solider Standard – lang genug, um einen Schub von Änderungen zu einem Aufruf zu bündeln, kurz genug, dass sich das Ergebnis noch sofort anfühlt:

  let timer;
  function onFilterChange() {
    clearTimeout(timer);
    timer = setTimeout(fetchAvailability, 300); // ms – bündelt einen Schub von Änderungen zu einem Aufruf
  }

• Die Location-Lesezugriffe pro Seitenaufruf cachen, nicht pro Interaktion. Profil, Öffnungszeiten, Speisekarten, Ressourcen und Raumplan ändern sich nur, wenn ein Betreiber in der Konsole etwas bearbeitet – jeden einmal beim Öffnen der Seite lesen und für den Rest des Besuchs weiterverwenden, wie es das Standard-Widget bereits tut (Venue → Caching).

• Das Datum abfragen, das ein Gast tatsächlich ansieht, nicht einen weiteren Bereich „zur Sicherheit“. 14 Aufrufe für einen sichtbaren Datumsstreifen sind legitim; ein Monat, zu dem niemand scrollen wird, nicht.

• Bei 5xx zurückweichen, nicht bei 429 – ein 429 gibt es noch nicht. Ein exponentielles Backoff mit Jitter bei einer 5xx-Antwort (unser Fehler, nicht der des Gasts) ist die eine Retry-Logik, die sich heute schon lohnt.

Nächste Schritte

• Authentifizierung – der Schlüssel, der jeden Aufrufer identifiziert.
• Verfügbarkeit – der Endpunkt, um den es beim Entprellen oben vor allem geht.
• Fehler – jedes Problem, das die API heute zurückgeben kann; 429 gehört noch nicht dazu.