SmartLock (3): Entwurf der Web-API mit Express.js

In den beiden vorherigen Blogbeiträgen haben wir bereits etwas über die Idee hinter „Smart Lock“ gehört. Außerdem haben wir dort die verwendeten Hardwarekomponenten vorgestellt. In diesem Blogbeitrag soll es nun etwas Softwarelastiger werden.

Die Softwareentwicklung beschäftigt sich, grob umrissen, mit zwei Themenbereichen: Dem Frontend und dem Backend. Im Frontend werden komfortable Nutzeroberflächen entwickelt und bereitgestellt, in denen sich der Nutzer möglichst leicht zurechtfinden soll. Die Geschäftslogik wird im Frontend sehr schlank gehalten, da Clients häufig nur über begrenzt leistungsfähige Hardware verfügen. Die Geschäftslogik wird dann in das performantere Backend ausgelagert.

Ein weiterer Vorteil dieser Architektur ist die strikte Trennung der implementierten Benutzeroberfläche und der Geschäftslogik, wodurch die Wartbarkeit enorm erleichtert wird. In diesem Blog soll es primär um die Ausgestaltung des Backend gehen. In einem spätern Blogbeitrag wird dann auch das Frontend thematisiert.

Abbildung 1: Logo von node.js und express.js

Unser Backend basiert auf der Javascript Laufzeitumgebung Node.js. Mithilfe von Node.js kann Javascript auch für die Backendentwicklung eingesetzt werden. Des Weiteren bietet Node.js mit dem Packagemanager npm eine Vielzahl von Bibliotheken an, die bei der Softwareentwicklung unterstützen können. Bei der Entwicklung von Web-APIs in Kombination mit node.js kommt häufig das Framework express.js zum Einsatz. Auch bei unserem Projekt baut auf node.js express.js auf. Mithilfe von express.js können sehr einfach Routen auf Grundlage des REST Prinzips erstellt werden. Weiterhin wird der Umgang mit HTTP-Anfragen und Antworten durch eine einfache Auswertung der URL-Parameter oder des Request-Bodies ermöglicht. Außerdem lässt sich mit express.js besonders gut eine Middleware zwischen Client und Web-API realisieren.

Tabelle 1: Einge Routen der Web-API

Bezeichnung	HTTP-Verb	Route	Request	Response
Login des Admins	POST	/v1/login	admin, password	admin, loginStatus
User Liste anfordern	GET	/v1/userList	–	Liefert alle User in einem Array zurück.
User anhand einer Id löschen	DELETE	/v1/user/userId	–	Liefert den gelöschten User zurück.
Lösche die Bilder eines Users in der KAIROS Galerie	DELETE	/v1/image/userId	–	imageDeleted
Füge einen neuen User hinzu und lade ein Bild des Users (optional) in der KAIROS Bibliothek hoch	POST	/v1/addUser	Daten des zu erstellenden Users.	Bei Erfolg werden die Userdaten zurückgeliefert. Ansonsten wird ein leeres Objekt versandt.
Erhalte eine Liste mit allen Usern, die das Haus in einem definierten Zeitraum betreten haben	GET	/v1/getAccessList/from/to	–	Alle User die das Haus im definierten Zeitraum betreten haben.

Unsere express.js Web-API besteht aktuell aus zwölf unterschiedlichen Routen. Diese erwarten und versenden Daten im JSON Format. In diesem Blog werden nachfolgend sechs dieser Routen vorgestellt. Diese sind in Tabelle 1 zu erkennen. Alle Routen der API finden sich hier. In unserer API ist der Admin eine Person, die sich in die Weboberfläche anmelden kann. Zudem gibt es den User. Dieser repräsentiert eine berechtige Person, die das Haus betreten darf.

Die erste Funktionalität unserer Web-API sollte eigentlich nahezu jede Weboberfläche bieten. Die Möglichkeit sich einzuloggen. Über die Route /v1/login ist der Login bei uns aufrufbar. Dabei muss der Client im Body des http-Requests den Login Namen und das korrekte Passwort versenden. Ist der Login erfolgreich, wird in der Antwort des Servers der Login Status auf true gesetzt.

Die zweite Route, die in Tabelle 1 zu erkennen ist, ermöglicht es Listen der User anzufordern. Die Route ist unter /v1/userList aufrufbar und erwartet keine Request Parameter. Der zurückgelieferte Array besteht aus einzelnen Userobjekten, in denen die Daten der User zu finden sind.

Über den Pfad /v1/user/userId ist die nächste Route aufrufbar. Hierrüber kann ein User, mithilfe des gelieferten URL-Parameters userId, in der Datenbank gelöscht werden. Als Antwort kommuniziert der Server dann den gelöschten User an den Client.

Eine weitere wichtige Schnittstellenfunktionalität ist das Löschen von Bildern in der KAIROS Galerie. In KAIROS sind sämtliche Bilder der User in einer Galerie gespeichert. Möchte nun ein User seine gespeicherten Bilder in der KAIROS Galerie löschen, ruft er die Route /v1/image/userId auf und übergibt seine userId als URL-Parameter. War das Löschen aller Bilder erfolgreich verschickt der Server eine entsprechende imageDeleted flag.

Können Bilder in der KAIROS Galerie gelöscht werden muss es auch einen Weg geben diese dort zu hinterlegen. Hierfür dient die nächste API-Funktionalität. Wird die Route /v1/addUser vom Client aufgerufen, kann dieser im HTTP-Body alle Daten des anzulegenden Users bereitstellen. Der Server legt den User dann in der Datenbank an. Wurde ein Bild beigefügt, wird außerdem eine Aufforderung an die KAIROS API gesendet dieses in der Galerie hochzuladen.

Die letzte API-Funktionalität, welche ich hier präsentieren möchte, ist eine Option Log Daten der User abzufragen. Dafür ruft der Client die Route /v1/getAccessList/from/to auf. Mithilfe von from und to muss entsprechend ein Zeitraum abgesteckt werden. Als Antwort erhält der Client vom Server alle User die in diesem Zeitraum das Haus betreten haben.

Soviel erstmal zu unserer Web-API. Über Feedback und sonstige Anregungen würde ich mich freuen :). In unserem nächsten Blogbeitrag wird sich @alexanderfuchs ein wenig mit dem Thema Backendsicherheit beschäftigen.