Grundlagen der API
Womit haben wir es zu tun?
Im Kern handelt es sich um ein Headless CMS. Das CMS-UI ("CMS-Frontend" oder "Pflegeanwendung") bietet anhand der benötigten Datentypen eine dynamisch erstellte Benutzeroberfläche an um Inhalte zu pflegen. Die Konfiguration des CMS erfolgt über eine HTTP/REST API. Auch die Datenpflege selbst verwendet eine analoge HTTP/REST API, die auch von der Pflegeanwendung verwendet wird.
Wie erfolgt die Konfiguration?
Hier wird der Begriff API verwendet, der letztlich eine HTTP/REST CRUD Schnittstelle auf eine einzelne Objektklasse beschreibt. Eine API wird mit einer Beschreibung einer Objektklasse angelegt (POST) und kann nachträglich auch verändert (PUT) und natürlich auch wieder gelöscht werden (DELETE). Einige Methoden erlauben das Auffinden (GET) von Schnittstellen und deren Beschreibung.
Zur Bereitstellung einer Mandantenfähigkeit unterteilt sich der Name einer API in zwei Teile, die in einer URL durch einen Schrägstrich geteilt sind, e.g. tutorial/demo1. Der erste Teil (tutorial) wird als Namensraum bezeichnet, der zweite (demo1) ist der eindeutige Name der API in diesem Namensraum. Für eindeutige Namensräume kann etwa das Konzept der umgekehrten Domänennamen verwendet werden, um Mandanten zu trennen - wie zum Beispiel in der Android und Java Welt üblich.
Warum mandantenfähig?
Meistens gibt es natürlich nur einen Endkunden für den das CMS implementiert wird. Allerdings ist es oft der Fall, dass mehrere Dienstleister verschiedene Software-Anwendungen für ein Projekt erstellen. Mandanten sind also in dem Fall unterschiedliche Dienstleister sprich Firmen die eventuell einen eigenen Namensraum für ihre Software in einem Projekt verwenden wollen. Also ein Mandant verfügt auch über einen Namensraum in der Form: Mandant/ Data_for_xy
Wie werden Daten gepflegt?
Ist eine API einmal angelegt, so wird automatisch eine HTTP/REST CRUD Schnittstelle zur Pflege angeboten. Beim Anlegen (POST) und ändern (PUT) von Daten werden diese gegen die Beschreibung der Objektklasse geprüft. Für diese Prüfung wird als Grundlage der fastest-validator verwendet, der in Client und Server eingesetzt werden kann. Die generische CMS-UI kann mit Hilfe dieser Beschreibung nicht nur passende Formulare aufbauen, sondern bereits Vorabprüfungen vornehmen - sicher nicht vollständig, da einige Prüfungen nur im Server möglich sind.
Welchen Zugriffsschutz gibt es?
Ein Rechtesystem erlaubt es über die Namensräume nicht nur eine Mandantenfähigkeit herzustellen. Vielmehr ist auch eine Einschränkung des Zugriffs auf Daten möglich.
Hinweis: aktuell wird zwischen Lese- und Schreibrechten auf ganze Objekte unterschieden. Eine zukünftige Erweiterung könnte die Rechte bis auf einzelne Felder herunterbrechen.
Wie fängt man am besten an?
Ein im übernächsten Kapitel folgendes kleines Tutorial beschreibt schon einmal die ersten Schritte, aber interessant wird es vermutlich erst in den Details. Das Tutorial ist aber wichtig, um die wenigen Grundlagen zu verstehen, um mit dem CMS kommunizieren zu können.
Auch wenn das eigentlich erst einmal zweitrangig ist, sollte man sich zuerst mit dem grundlegenden Sicherheitskonzept vertraut machen. Nach einem Verständnis der API Schnittstelle weiß man alles Notwendige zur Konfiguration des CMS.
Tatsächlich sind das aber alles Einmalaktionen, viel spannender ist eigentlich die Daten Schnittstelle, mit der Daten ins CMS eingebracht, ausgelesen, modifiziert und wieder gelöscht werden können. Diese Schnittstelle ist eigentlich so einfach, dass hier auch eine sehr kurze Einführung reichen wird, um mit dem CMS arbeiten zu können.
Hinweis: Aktuell gibt es eine reine CRUD Schnittstelle. Bei weiterem Ausbau des CMS gibt es sicher auch genug Ideen für darüber hinausgehende HTTP/POST Aktionen, die dann über Erweiterungen eingebunden werden können.