Eine Schnittstelle, mit der andere arbeiten können

Eine Schnittstelle wird selten von denen benutzt, die sie bauen. Am anderen Ende sitzt ein App-Team, eine Partnerfirma oder ein anderes System, und für die zählt vor allem, ob sie ohne Rückfragen damit arbeiten können. Deshalb entstehen hier Entwurf und Dokumentation zuerst: Welche Zugriffe gibt es, welche Daten liefern sie, wie sieht eine Antwort aus, was passiert im Fehlerfall. Erst wenn dieser Entwurf besprochen ist, beginnt die Umsetzung. Das klingt umständlich und spart in der Praxis die meiste Zeit, weil Missverständnisse auf dem Papier billiger sind als im Code.

Bei der Anmeldung hängt der richtige Weg daran, wer zugreift. Für eigene Anwendungen genügen meist Zugangstoken, wie Laravel sie mitbringt. Greift eine fremde Anwendung im Namen eines Nutzers zu, kommt das übliche Verfahren mit ausdrücklicher Zustimmung und begrenzter Gültigkeit zum Einsatz. Partner, die nur Daten abholen, bekommen einen eigenen Zugang mit klar begrenzten Rechten. In allen Fällen gehören Rechte, eine Begrenzung der Zugriffe pro Zeitraum und ein Protokoll dazu, damit im Zweifel nachvollziehbar ist, wer wann was abgerufen hat.

Der Teil, der später über Ärger oder Ruhe entscheidet, ist der Umgang mit Änderungen. Sobald andere die Schnittstelle nutzen, darf sie sich nicht unangekündigt ändern: Ein umbenanntes Feld legt eine App lahm, die im App Store liegt und nicht mal eben aktualisiert wird. Deshalb wird von Anfang an versioniert, Ergänzungen laufen zusätzlich statt ersetzend, und Abkündigungen bekommen eine Frist. Wie damit umgegangen wird, steht in der Dokumentation, bevor der erste fremde Zugriff kommt.

Zum Lieferumfang gehören automatisierte Tests für die Endpunkte. Bei einer Schnittstelle sind sie mehr wert als anderswo, weil niemand von Hand durchklicken kann, was eine Maschine benutzt: Ein Test zeigt in Sekunden, ob nach einem Update noch dieselbe Antwort herauskommt. Dazu kommen eine Testumgebung mit Beispieldaten, gegen die das andere Team entwickeln kann, bevor es live geht, und die Dokumentation mit Beispielanfragen und Beispielantworten.

Nicht jede Aufgabe braucht übrigens eine eigene Schnittstelle. Sollen zwei bestehende Systeme Daten austauschen, ist oft ein vermittelndes System der bessere Weg, und wo eine Oberfläche und ihr Backend ohnehin zusammengehören, spart der TALL-Stack die Schnittstelle ganz. Was im konkreten Fall passt, wird im Erstgespräch geklärt.

Die Zusammenarbeit läuft standardmäßig zu 100 % remote und damit ortsunabhängig, direkt mit Auftraggebern, als Verstärkung für Agenturen und über IT-Vermittler. Code geht über Git, die Testumgebung steht dem anderen Team zur Verfügung, die Abstimmung läuft über Mail, Slack, Teams oder kurze Video-Calls. Werden dabei echte Personendaten verarbeitet, gehört ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO zum Auftrag. Gearbeitet wird aus dem eigenen Büro im kontorworx-Coworking-Space in Rheine, persönliche Termine vor Ort sind nach Absprache möglich.