PRINZIP — API FIRST
API First
Wir entwerfen die Schnittstellen zuerst und die Oberfläche darauf. Das trennt sauber, was ein System kann, von der Frage, wie es dargestellt wird — und macht die Schnittstelle zum Ort, an dem Sicherheit durchgesetzt wird.
Warum wir das so machen
Die Begründung.
Wenn die Schnittstelle zuerst entsteht, ist sie ein Vertrag und kein Nebenprodukt. In der RetterApp bedienen sich die mobile App und das Admin-Panel aus demselben Backend: eine einzige Stelle, an der die Fachlogik lebt. Jede Oberfläche ist nur eine Sicht darauf.
Der zweite, oft unterschätzte Effekt ist Sicherheit. Die Schnittstelle ist das kontrollierte Tor: Dort wird entschieden, wer was sehen darf, dort werden Daten maskiert, dort greift die Begrenzung der Anfragen. In unserer Geoplattform ist der Backend-Proxy nicht nur Fassade, sondern die Stelle, an der Datenschutz erzwungen wird — die App kennt gar keinen Zugangsschlüssel, das Backend hängt ihn serverseitig an.
Und weil Schnittstellen überleben, behandeln wir sie wie Verträge. Wer heute integriert, soll in zwei Jahren nicht umbauen müssen, weil wir ein Feld umbenannt haben — deshalb sind Versionierung, Fehlerformat und Beschreibung festgelegt und nicht dem Zufall überlassen.
Was du davon hast
Deine Daten und Funktionen werden für neue Kanäle wiederverwendbar: Eine zweite App, ein Partner-Zugang oder eine Integration in ein Fremdsystem sind ein überschaubares Zusatzprojekt statt ein Umbau von Grund auf.
Konkret
Die Entscheidungen dahinter.
Versionierung im Pfad
Änderungen brechen keine bestehenden Aufrufe. Was einmal ausgeliefert wurde, bleibt erreichbar, bis es bewusst abgelöst wird.
Einheitliches Fehlerformat
Maschinenlesbare Fehler nach Standard, mit stabilen Codes und verständlichen deutschen Texten — statt HTTP-Status plus Textfragment.
Spezifikation aus dem Code erzeugt
Die Schnittstellenbeschreibung entsteht aus denselben Schemata, die auch die Eingaben prüfen. Dokumentation kann nicht veralten, ohne dass es auffällt.
Schlüssel bleiben serverseitig
Zugangsdaten für Fremd- und eigene Dienste liegen nie in einer App. Das Backend proxyt, prüft und begrenzt — mit Pfad-Freigabeliste gegen Missbrauch.
Ausfälle Dritter einkalkuliert
Ein Aufruf, der zweimal ankommt, wirkt nur einmal; Wartezeiten sind begrenzt, und eine Notabschaltung koppelt einen hängenden Fremddienst ab — ein fremder Ausfall darf dein System nicht mitreißen.
Belege
Woran du uns messen kannst.
- 212 Endpunkte in Produktion in der RetterApp (Stand 16.08.2026), davon 22 ohne Anmeldung erreichbar — mobile App und Admin-Panel nutzen dieselbe Schnittstelle.
- Einheitliches Fehlerformat nach RFC 7807 (heute RFC 9457), mit stabilen Codes und deutschen Texten.
- Das Backend der RetterApp nutzt die Geoplattform produktiv über deren reguläre, schlüsselgesicherte Schnittstelle — der Schlüssel liegt serverseitig, die App sieht ihn nie.
- In Produktion ist die Schnittstellen-Dokumentation nicht öffentlich erreichbar, damit die interne Angriffsfläche nicht offenliegt.
Häufige Fragen
Was oft gefragt wird.
Wir haben ein Altsystem, das bleiben muss. Geht das?
Ja, und das ist einer der Hauptgründe für dieses Vorgehen. Wir kapseln das Altsystem hinter einer sauberen Schnittstelle. Neue Anwendungen sprechen nur noch mit dieser Schnittstelle, und du kannst das Altsystem später Stück für Stück ablösen, ohne dass die Anwendungen davon etwas merken.
Bekommen wir eine Dokumentation der Schnittstelle?
Ja — und zwar eine, die aus dem Code selbst entsteht statt daneben gepflegt zu werden. Damit beschreibt sie den tatsächlichen Stand. In Produktion ist die öffentliche Ansicht abgeschaltet; für dein Team ist sie verfügbar.
Weiterlesen
Passt dazu.
Die anderen Prinzipien.
Jedes für sich erklärt, warum wir so bauen — und woran man es nachprüfen kann.