Gebäudeversicherung REST API

Aufgabenbereich: Zend Framework 2, Zend Framework 3, PHP7, REST
Status: abgeschlossen (Juli 2018)
Kunde: vs vergleichen-und-sparen GmbH

Projektbeschreibung

Für den Kunden wurde über einen Entwicklungszeitraum von knapp einem Jahr eine REST API für die Tarifierung und Antragsstellung zur Wohngebäudeversicherung entwickelt. Die API wurde an das bereits bestehende Partner Programm des Kunden gekoppelt, so dass bestehende Partner mit einer Partner ID die API hätten nutzen können. Auf Basis dieser Schnittstelle wurde zeitgleich auch der neue Vergleichsrechner für die Gebäudeversicherung programmiert. Über den Vergleichsrechner wurden Eingabedaten gesammelt, die dann an die API gesendet wurden. Die API hat die Daten vollständig validiert. Im Fehlerfall wurden entsprechende Fehlermeldungen auf Basis von HTTP Status Codes und Klartext Fehlermeldungen zurückgegeben. Waren alle Eingaben in Ordnung, hat die API bis zu 360 Tarife auf Basis dieser Eingaben berechnet und als Ergebnis zurück geliefert.

Die komplette Kommunikation zwischen Vergleichsrechner (Consumer) und API (Provider) erfolgte über POST Requests im JSON Format. Während der Vergleichsrechner das User Interface auf Basis des Zend Framework 2 bereit gestellt hat und alle eingegebenen Daten ebenfalls mit Hilfe dieses Frameworks versendete, arbeitete die API bereits auf Basis des Zend Framework 3. Mit dem Zend Framework 3 konnten gegenüber der Vorgängerversion wesentliche Geschwindigkeitsvorteile erzielt werden. Obwohl der Vergleichsrechner erst Daten an die API senden und von der API empfangen musste, war die Berechnung des Ergebnisses merklich schneller als in der aktuell eingesetzten Version des Vorgänger-Vergleichsrechners aus dem Jahre 2013.

Das User Interface stammte aus der Feder der hauseigenen Webdesign Abteilung des Kunden. Wie im zuvor entwickelten Vergleichsrechner zur Gewässerschadenhaftpflichtversicherung wurde auch hier das moderne, selbsterklärende Design eingesetzt. Moderne Erweiterungen wie die Constraint Validation API gestalteten das Eingabeformular sehr dynamisch. Eingaben wurden direkt bei Verlassen des Eingabefeldes vorvalidiert, so dass ggf. Fehler direkt im UI angezeigt werden konnten, ohne ein Request an den Server zu senden. Natürlich fand auch eine serverseitige Prüfung der abgesendeten Daten statt.

Alle Daten, die die API bereit gestellt hat, stammten aus den Datenbanken des Kunden. In einem weiteren Schritt hätte die API verschiedene Tarifierungsschnittstellen nach BiPRO Norm ansteuern sollen, so dass Tarifierungsergebnisse über die BiPRO Schnittstellen der verschiedenen Versicherungsunternehmen hätten ermittelt werden können.

Was ist eigentlich eine API?

Eine API ist ein Application Programming Interface, welches einem Programmierer vorschreibt, wie eine Applikation zu programmieren ist. Vereinfacht ausgedrückt also die Bauanleitung für ein Programm, die sicher stellt, dass Abläufe und Daten auch so geliefert werden, wie man sie gern haben möchte. Also eine Schnittstelle für Anwendungsentwicklung. Für die Anwendung (Gebäudeversicherung Vergleichsrechner) bedeutete dies, dass komplexe Bestandteile, wie z.B. die Validierung von Daten, die Berechnung von Tarifen und das Versenden von Antragsdaten an das CRM System des Kunden in die Schnittstelle ausgelagert wurden. Somit war es möglich leichtgewichtige Anwendungen zu entwickeln, die lediglich Daten an die API liefern und das zurück gelieferte Ergebnis auswerten und darstellen. Durch das JSON Format war sicher gestellt, dass Programme in jeder Programmiersprache auf Basis dieser API entwickelt werden konnten, die das JSON Format interpretieren können. Denkbar wären hier z.B. eine Desktop Anwendung für Makler oder ein einfaches Touch Display in einem Terminal einer Bank, welches dem Kunden ermöglicht aktuelle Ergebnisse zu berechnen und die berechneten Daten dann für einen Besprechungstermin zum Kundenberater zu senden. Bereits zum Entwicklungszeitraum haben mehrere Versicherungsunternehmen Interesse am bereits bestehenden Vergleichsrechner zur Gebäudeversicherung gezeigt, da dieser zu den umfangreichsten Anwendungen auf dem Markt gehört. Mit einer API hätte man hier allen Interessenten ein mächtiges Werkzeug an die Hand gegeben. Gleichzeitig wäre man unabhängig von Endgeräten gewesen. Sowohl für Desktop Computer, Tablets und auch andere mobile Geräte hätte man eigene Entwicklungen generieren können. Selbst sprachgesteuerte Endgeräte, wie Alexa und Co. hätten potentielle Endgeräte für diese API sein können. Potential war auf jeden Fall vorhanden.

Was ist aus der API geworden?

Leider hat sich der Kunde dazu entschieden die Zusammenarbeit zu beenden und somit auch die vielversprechende API zur Gebäudeversicherung nicht final entwickeln zu lassen. Bei Übergabe des Projekts wurde der API Server bzw. die API abgeschaltet. Der Kunde hat sich dazu entschieden keine eigenen Vergleichsrechner mehr zu entwickeln und Vergleichsrechner eines Mitbewerbers zu nutzen. Eine überraschende und gleichzeitig bedauernswerte Entscheidung in Anbetracht des Potentials dieser API.

In diesem Sinne wünsche ich der vs vergleichen-und-sparen GmbH viel Glück und weiterhin Erfolg für die Zukunft.

Bildquelle: Pixabay / CC0 Creative Commons

About Author: Marcel
Ich bin Senior PHP Developer bei MM Newmedia. Seit 2005 bin ich begeisterter Webentwickler und arbeite als Freelancer für namenhafte Firmen und entwickle jede Menge abgefahrenes Zeug und berichte darüber in meinem Blog.

2 thoughts on “Gebäudeversicherung REST API

  • Bei BiPRO kannste mal unter RNext und BiBRO als begriff suchen. Du wirst da interessante Neuigkeiten finden. SG

    • Hi Marcel,

      BiPRO RNext ist in der Tat ein spannendes Thema. Das Projekt RNext wurde aber erst auf dem diesjährigen BiPRO Tag vorgestellt und mit ersten spruchreifen Umsetzungen ist laut BiPRO erst gegen Ende des Jahres zu rechnen. Wirklich realistische Termine stehen noch nicht fest. Die RNExt Ankündigung geht in die richtige Richtung, dauert meiner Meinung nach aber viel zu lange.

      Für ein Projekt der Firma zeitsprung GmbH & Co KG habe ich einen PHP Wrapper entwickelt, der vor einen vorhandenen BiPRO TAA Prozess eines Providers gesetzt wird und die zu sendenden als auch die zu empfangenden Daten als JSON Format zur Verfügung stellen kann, so dass diese in einer REST Schnittstelle genutzt werden können. Wenn es also allein um die Verwendung des JSON Datenformats geht, sind einige Unternehmen schon sehr viel weiter, als es die BiPRO aktuell ist.

      Grundsätzlich bin ich sehr gespannt, wie das Projekt „RNext“ am Ende aussehen wird. Aktuell wird da vieles richtig gemacht.

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.