Weiterentwicklung der API

In diesem Kapitel wird die Weiterentwicklung der Monitor-API diskutiert, welche möglichen Aufgabe diese übernehmen kann und was noch verändert werden muss.

  • Aufsplitten der Blueprints

Durch die große Arbeitslast durch das SoRa-projekt sollte dieses in einen neuen Microservice gekapselt werden. Allegemein wäre zu überlegen ob nicht die API in Ihrer Gesamtheit aufgesplittet wird, in mehrere Microservices.

OAuth (Open Authorization) ist ein offenes Protokoll, das eine standardisierte, sichere API-Autorisierung für Desktop-, Web- und Mobile-Anwendungen erlaubt.Quelle

Mit der Verwendung dieser API wäre es möglich, die Nutzerverwaltung auch für den Monitor auszuweiten und dem angemeldeteten Nutzer spezifische Inhalte und Funktionen zu bieten.

  • Ausbau des Admin-Bereichs und OGC-Services

Im Moment ist es nur möglich einen Update der Dienste anzubieten. Perspektivisch wäre es auch wichtig die API um die REST-CRUD Methoden zu erweitern und diese in der GUI anzubieten.

Ein weiterer Punkt wäre es, alle Aufgaben des IÖR-Monitor-Backends auf den Flask-Microservice zu übertragen und viele kleine Dienste zu orchestrieren.

  • Ablösen des alten MapServers durch Flask für die Rasterdarstellung des Monitors

Im Moment wird die Rasterdarstellung des IÖR-Monitors noch durch PHP5 durch Kombination mit einem veralteten MapServer auf einem anderen Server realisiert. Hierbei wird auch nur durch PHP ein Mapfile erstellt, welches die abgefragten Metadaten aus der MySQL Datenbank in das Mapfile schreibt. Diese Aufgabe kann auch die OGC-Factory übernehmen, welche auch einzelne Mapfiles schreiben kann. Hierfür muss die Methode createSingleService() des instanziierten WmsService aufgerufen und der gewünschte Pfad angegeben werden. Das erstellte Mapfile muss noch via CGI nach außen freigegeben und an den Monitor geschickt werden.