.social

MobilBonus & Gleis7 API

August 2015

Für die beiden SBB Apps Gleis7 und MobilBonus durfte ich die jeweiligen Schnittstellen End2End betreuen (Design, Architektur, Implementierung, Betrieb).

webapi

Briefing

Die Anforderungen an die Schnittstelle wurden gemeinsam mit unserem Implementierungs-Partner für die Apps definiert, es waren also von Beginn weg sehr technische Definitionen. Da die Apps technologisch auf derselben Code-Base basierten, konnten auch die beiden Schnittstellen viele Funktionalitäten teilen, einzig die Terminologie war eine andere.

Lösungsansatz

Für mich war dies das erste "API-only" Projekt ohne jegliches Frontend, was auch einiges an Desk-Research bezüglich Authentifizierung, Best Practice etc. bedeutete. Die API war jedoch weit entfernt von einer REST-API, es waren nur sehr limitierte Daten-Manipulationen möglich. Aus diesem Grund entschieden wir uns für eine eher klassische SOAP-Architektur (Method-Calls), jedoch auf JSON-Basis.

Als externe Abhängigkeit gab es einen Service von den SBB zu beachten, welcher uns auf Basis einiger Identifikations-Merkmale die kompletten Kundendaten sowie die entsprechenden Angaben zum aktuellen Abonnement zurücklieferte.

Da die API ein reiner Backend-Layer war (vorgeschaltet war eine Frontend-API welche direkt durch die App aufgerufen wurde), war im Bereich Caching nach den ersten Testläufen nichts vorgesehen. Als wir jedoch mit der MobilBonus-App starteten, wurden die Requests für eine Abonnements-Validierung nicht mehr tragbar (weder performance- noch timing-technisch); wir reagierten innerhalb von weniger Stunden mit einer Migration in die Cloud (Azure) sowie einem stabilen Caching-Layer. Lesson learned: Caching ist selten bis nie ein Overhead, kann im Ernstfall aber wahnsinnig viele Nerven schonen.