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.
Warum proprietäre Antwortformate keine gute Idee sind
Fragen Sie, warum eine API ein verschachteltes, eigenes Objektmodell statt einer einfachen, flachen JSON-Struktur zurückgibt, und die ehrliche Antwort ist selten eine technische. Eine proprietäre Struktur macht eine Abfrage weder schneller noch genauer. Sie macht die Antwort schwerer austauschbar, denn jeder Feldname, jede Verschachtelungsebene und jeder eigene Statuscode, den Ihr Code verarbeiten lernt, ist ein kleines Stück anbieterspezifisches Wissen, das fest in Ihre Anwendung eingebaut ist.
Wir halten das für verkehrt herum. Ein Antwortformat sollte die Daten beschreiben, nicht den Anbieter. Koordinaten, Adressen, Zeitverschiebungen und Höhen sind dieselben Konzepte, egal wer die Anfrage beantwortet, also sollte die zurückgegebene Struktur ungefähr so schlicht sein wie die Konzepte selbst. Deshalb liefern auch 17 unserer Hosts exakt die Antwortstruktur der API eines anderen Anbieters: Die Daten sind unsere, aber die Struktur ist eine, die Ihr Code vielleicht schon versteht, denn es ist eigentlich gar nicht unsere Aufgabe, sie zu erfinden.
Proprietäre Formate sammeln außerdem gern Eigenheiten an, die nichts mit den zugrunde liegenden Daten und alles mit der internen Geschichte eines Anbieters zu tun haben. Ein Feld wird für eine interne Migration umbenannt, und der alte Name bleibt als veralteter Alias bestehen, den niemand entfernen will. Ein Status wird in einem Endpunkt als String und in einem anderen als numerischer Code dargestellt, weil beide Jahre auseinander von verschiedenen Teams gebaut wurden. Nichts davon ist böswillig. Es passiert einfach, wenn ein Format nie gegen einen externen Standard entworfen wird, sondern nur gegen die sich entwickelnde Codebasis eines Unternehmens.
Die Lösung ist nicht kompliziert: Wählen Sie eine schlichte Struktur, dokumentieren Sie sie einmal und halten Sie sie stabil. Das tun wir bei unseren eigenen nativen Endpunkten, und bei den Kompatibilitäts-Hosts gehen wir einen Schritt weiter: Wir bilden die Struktur eines anderen Anbieters exakt nach, sodass eine Codebasis, die diese Struktur bereits parst, außer einer Basis-URL und einem Schlüssel überhaupt keine Änderungen braucht. Das ist eine größere Verpflichtung, als es klingt. Es bedeutet: Wenn die nachgebildete Struktur einen ungeschickten Feldnamen oder eine inkonsistente Verschachtelung hat, behalten wir die Ungeschicklichkeit bei, denn der gesamte Wert des Kompatibilitäts-Hosts liegt in der Treue, nicht in der Verbesserung.
Ein proprietäres Format wird manchmal damit verteidigt, dass es einem Anbieter Raum gibt, mit der Zeit reichhaltigere Daten hinzuzufügen. Wir glauben nicht, dass Reichhaltigkeit eine ungewohnte Struktur erfordert. Optionale Felder wie Höhe oder Details zu IP-Bedrohungen können als Ergänzungen neben einer Standardantwort stehen statt sie zu ersetzen. So muss ein Aufrufer, der sie nicht anfordert, nie um sie herum parsen, und ein Aufrufer, der sie anfordert, erhält sie, ohne ein neues Format lernen zu müssen.
Bei alldem geht es nicht wirklich um JSON-Formatierung als technische Vorliebe. Es geht darum, wer die Kosten einer Strukturentscheidung trägt. Ein proprietäres Format legt diese Kosten auf jeden Kunden, der die Antwort jemals lesen muss. Ein schlichtes oder nachgebildetes Format legt sie auf uns, in Form der Entwurfsarbeit, die Dinge vorhersehbar zu halten. Dort gehören die Kosten hin.