Nach dem Frontend beschreibe ich hier das Backend zur Speicherung der Abonnements von Push Nachrichten. Ich implementierte es nach dem REST Paradigma. Das Javascript schreibt die Abonnementdaten, die es vom Browser bekommt, per POST in die Ressource pmp.gawehns.de/subscription. Der Webserver speichert diese Daten in einer Datenbanktabelle.
Für den Versand der Push Nachrichten greift ein Programm auf meinem Mac per GET auf pmp.gawehns.de/subscription zu. Der Webserver fragt alle Daten ab und liefert die Abonnementdaten zurück. Das Programm verschlüsselt die Push Nachricht mit dem privaten Schlüssel und schickt diese an den Pushserver. Die Browser mit Abonnement fordern diese Nachrichten dann an. Falls ein Versand fehlschlägt, löscht das Programm den Eintrag per DELETE aus der Ressource pmp.gawehns.de/subscription.
So geht eine Implementierung nach „REST Paradigma“.
- Brauche ich dafür ein Framework?
- Was ist eigentlich das revolutionäre an diesem doch recht offensichtlichen Ansatz?
minimales php REST per .htaccess
Zunächst implementierte ich subst.php mit einer Abfrage nach der Art des Aufrufs. Wenn hier ein POST stand, gab ich „nun sollte eingetragen werden“ zurück. Bei einem DELETE und GET gab ich andere Meldungen zurück.
Danach fand ich eine Beschreibung der pdo Schnittstelle und schon implementierte sich der Zugriff auf die SQL Datenbank nahezu von selbst. Die URL des pushservers sollte als Primärschlüssel dienen. Mit einer URL Base64 Kodierung funktionierte es.
Nicht ganz so offensichtlich waren die Überschreibungsregeln in der Datei .htaccess. Je nach Version und Konfiguration des Webservers waren Unterschiede. Ich stellte fest, dass meine lokale Installation sich doch von der auf one.com unterschied. Mit Geduld und nach ein paar Versuchen stand die Abbildung von pmp.gawehns.de/subst.php nach pmp.gawehns.de/subscription.
Mit .htaccess kann ich auch Sicherheitsregeln einbauen, damit nur kontrolliert auf eine Ressource zugegriffen werden kann. Für den Fall der Abonnements von Push Nachrichten kann ich darauf verzichten. Zum einen muss das Eintragen ohne jegliche Überprüfung erfolgen, zum anderen müssen die Nachrichten sowieso verschlüsselt werden. Einzig das unberechtigte DELETE sollte überprüft werden. Für die erste Version habe ich darauf mal verzichtet.
Was ist das revolutionäre an REST?
Das Werk von Fielding aus dem Jahr 2000 forderte Zustandsübergänge (State Transfers) bei verteilten Systemen durch Dokumente zu repräsentieren. Diese verteilten Systeme arbeiten zusammen um ein Ziel zu erreichen. Diese Systeme haben jedes für sich Zustände, genauso wie das gesamte System Zustände durchläuft.
So arbeiten die Steuerungen einer Abfüllanlage miteinander zusammen, damit die Flaschen gefüllt, verschlossen und etikettiert werden. Jede der einzelnen Steuerungen hat Strom, ist gefüllt, bewegt sich mit einer Geschwindigkeilt, usw. Die ganze Anlage hat einen Durchsatz und erwirtschaftet einen Deckungsbeitrag.
Das herkömmliche Design solcher Anlagen war an die Zustände als solche gebunden. Die Maschinenbauer haben Automaten gebaut. Informatiker diese dann in der Steuerungssoftware verwendet. Das Design hat viele, unterschiedliche Information über die Zustände des Gesamtsystemens, dafür aber wenig Information über die Daten.
Betrachtet der Systemarchitekt das Gesamtsystem mit dem REST Blickwinkel, so stellt er die Daten und deren Dokumentation im Vordergrund. Die Resourcen Flasche/x/Inhalt, Flasche/x/Korken und Flasche/x/Etikett beschreiben den Zustand jeder einzelnen Flasche. Zu Zeiten von Big Data sind das genau die Daten, die es auszuwerten gilt.
Genauso sind für die einzelnen Automaten immer nur die Zustände interessant, die per Dokument beschrieben werden. In dem Fall einer Abfüllanlage wäre das z.B. Band/x/Geschindigkeit, Patrone/x/CO2Füllstand, usw. Mit dem Internet der Dinge werden solche Dokumente zugreifbar.