Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Ratenlimits sollten dokumentiert sein, nicht erst entdeckt werden
Es gibt eine bestimmte Art von schlechtem Morgen, der mit einem Anstieg fehlgeschlagener Anfragen beginnt und damit endet, dass ein Entwickler zum ersten Mal die Statusseite eines Anbieters liest und herauszufinden versucht, ob die Fehler auf einen Ausfall zurückgehen oder auf ein Limit, von dem er nie wusste. Dieser Morgen ist vollständig vermeidbar, und dass er in dieser Branche immer noch vorkommt, ist ein Versagen der Dokumentation, nicht der Infrastruktur.
Ein Ratenlimit ist kein Geheimnis. Es ist eine betriebliche Tatsache eines Systems, genau wie eine maximale Anfragegröße oder eine unterstützte HTTP-Methode, und es gehört an dieselbe Stelle: schriftlich festgehalten, bevor jemand es erreicht. Wir veröffentlichen unsere in der Dokumentation zu Ratenlimits, neben den Seiten zu Authentifizierung und Fehlern, sodass die Zahlen, mit denen ein Entwickler planen muss, verfügbar sind, bevor er die erste Zeile Integrationscode schreibt, und nicht erst nach dem ersten Nachmittag, der sich wie ein Ausfall anfühlt.
Dokumentation allein reicht allerdings nicht, denn Limits können davon abhängen, welchen Tarif Sie nutzen, und ein Dokument ist in dem Moment veraltet, in dem sich Ihr Kontostatus ändert. Deshalb enthält jede Antwort zusätzlich live Kontingent-Header: Ihr Limit, wie viel Sie verbraucht haben, wie viel kostenloses Kontingent übrig ist, wie viel vom gemeinsamen Kontingent Ihres Netzwerks verbraucht wurde, Ihr verbleibendes Prepaid-Guthaben und wann das Kontingent zurückgesetzt wird. Sie müssen kein Dokument mit Ihrem Dashboard abgleichen, um zu wissen, wo Sie stehen. Die Antwort kommt mit der Antwort selbst, bei jedem einzelnen Aufruf.
Manche Anbieter betrachten veröffentlichte Limits als Wettbewerbsnachteil, den man verbergen sollte, nach der Theorie, dass eine sichtbare Zahl Kunden dazu einlädt, sie herunterzuhandeln oder mit einem Konkurrenten zu vergleichen. Wir halten diesen Instinkt für verkehrt. Ein Limit, das niemand sehen kann, schützt die Infrastruktur des Anbieters nicht besser. Es bedeutet nur, dass ein Kunde die tatsächliche Zahl erst erfährt, wenn er sie bereits überschritten hat, im denkbar schlechtesten Moment für ein wachsendes Produkt, vor den Augen seiner eigenen Nutzer.
Hinzu kommt eine Designdisziplin, die das Dokumentieren von Limits im Voraus einem Anbieter auferlegt. Wenn ein Ratenlimit veröffentlicht wird, muss es eine echte Zahl sein, hinter der jemand zu stehen bereit ist, und keine vage interne Schwelle, die stillschweigend angepasst wird, sobald sie unbequem wird. Die Zahl aufzuschreiben und bei jedem Aufruf in die Antwort-Header zu setzen, bedeutet, dass das Limit tatsächlich das Limit sein muss, und zwar durchgängig, und genau diese Eigenschaft braucht ein Entwickler.
Ein Ratenlimit durch eine fehlgeschlagene Anfrage in der Produktion zu entdecken, ist kein Initiationsritus. Es ist ein Zeichen dafür, dass die Dokumentation ihre Aufgabe nicht erfüllt hat. Unsere soll dafür sorgen, dass Sie von diesem schlechten Morgen nur lesen, weil er jemand anderem passiert ist, und ihn nicht selbst erleben.