Title: M1.3.1: Allgemeines zu REST
Course: LF07 - Cyber-physische Systeme ergänzen - FI/ITSE - Raspberry Pi > Section: LS7.1: Messdatenerfassungssysteme funktional zusammenführen

Überblick

Ziel dieser Lernsituation ist ja, dass zwei oder mehrere cyberphysische Systeme Daten untereinander austauschen können. Neben dem MQTT-Protokoll stehen weitere zur Verfügung, die es erlauben, über eine bestehende Netzwerkverbindung zu kommunizieren. Hier geht es um das ReST Verfahren, das auf dem bekannten Hypertext Transfer Protocol (HTTP) aufsetzt.

Systeme unterscheiden sich in ihrer Hardware, dem Betriebssystem, der verwendeten Programmiersprache oder App. Um unterschiedliche Systeme miteinander kommunizieren lassen zu können, benötigen sie eine in den Eigenschaften festgelegte Schnittstelle, so wie sich beispielsweise Menschen mit unterschiedlichen Muttersprachen meist gut auf Englisch unterhalten können. In der Technik bezeichnet man eine solche Schnittstelle die Application Programming Interface (API).

Um sich einen Überblick darüber zu verschaffen, lesen Sie im Kurs der Networking Academy IoT Fundamentals - Connecting Things:  Chapter 3 "Software is Everywhere" --> 3.1 "Programming" --> 3.1.3 "Lending Intelligence" -->

- 3.1.3.3 "Software API"
- 3.1.4.4 "REST API"

(Diese Verlinkung ist nur wirksam für registrierte Kursteilnehmerinnen und Kursteilnehmer in der Networking Academy. Ein Registrierung und Kurseinschreibung ist möglich über netacad.com.

Was ist HTTP?

Das HyperTextTransferProtocol (HTTP) ist eine Protokollfamilie, die Regeln zur Übertragung von Daten in einem Netzwerk definiert. Am bekanntesten ist HTTP im Zusammenhang mit der Übertragung von Internetseiten in Browsern. Das HTT-Protokoll ist auf der Anwendungsschicht des OSI-Modells angesiedelt und beruht auf dem Request-Response-Mechanismus. Das bedeutet, dass zunächst eine Anfrage (Request) vom Client an den Webserver gestellt werden muss, bevor dieser antwortet (Response).

Bekannt und verbreitet sind die HTTP-Methoden GET (WWW-Seiten anzeigen) und POST (Formulare absenden auf WWW-Seiten). Neben diesen beiden Methoden, die vor allem bei der Mensch-Maschine-Kommunikation eingesetzt werden, bietet das Hypertext Transfer Protokoll eine elegante Möglichkeit, direkt zur Maschine-Maschine-Kommunikation genutzt zu werden:

Representational State Transfer (REST)

Basierend auf den im Internet verbreiteten und etablierten Infrastruktur (HTTP-Methoden, URLs) können verteilte Systeme über REST-Services miteinander kommunizieren.

REST-Schnittstellen werden genutzt, um Objekteigenschaften über das Netzwerk zu verwalten. Die verwalteten Objekte bei REST heißen Ressourcen. Beispiele für Ressourcen wären  z.B. ein Buch in einem Onlineshop, ein Sensorwert oder ein Adresseintrag. Diese Ressourcen werden im Netz durch einen Uniform Resource Locator (URL) identifiziert, beispielsweise: http://buchshop.de/buecher/123

Mit Hilfe der URL kann eine Ressource angezeigt oder angepasst werden. Hierzu werden CRUD-Methoden angeboten, das steht für create, read, update, delete.

HTTP hat für jede dieser CRUD-Methoden eigene Verben, die veranlassen, dass die Ressourcen entsprechend angepasst werden. Es können

- Informationen über die Ressource ausgegeben werden (per HTTP-GET),
- Daten der Ressource verändert werden (per HTTP-PUT),
- Ressourcen gelöscht werden (per HTTP-DELETE) und
- neue Instanzen der Ressource erstellt werden (per HTTP-POST).

Angesprochen wird die Ressource jeweils über ein und dieselbe URL, lediglich die gewählte HTTP-Methode sowie die Nachricht, die dem HTTP-Request angehängt wird, variiert. Die genannten HTTP-Methoden (jedes Verb) verfügen über unterschiedliche Eigenschaften (safe, idempotent, cachable), die für den Einsatz von REST-APIs von zentraler Bedeutung sind:

 |  | safe | idem-potent | cache
POST (create) | Anlegen einer neuen Ressource unter einer vom Server bestimmten URI; Da POST keinerlei Garantien gibt wird es auch für alle sonstigen Aktionen verwendet, für die es keine passende HTTP Methode gibt. | ❌ | ❌ | ❌
GET (read) | Informationen, die durch eine URI identifiziert werden in Form einer Repräsentation abgeholt. GET darf keine Seiteneffekte haben, muss idempotent und cachable sein (siehe unten)! | ✔️ | P | P
PUT (update, create) | Aktualisiert oder erstellt eine Ressource, deren URI aufgerufen wird | ❌ | P | ❌
DELETE (delete) | Löscht eine Ressource, deren URI im Request angegeben wird. | ❌ | P | ❌

RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

In dieser Request For Comments ist das Protokoll grundlegend beschrieben. Hier noch ein wenig Informationstheorie zu dem Thema.

HTTP-Methoden sind sicher (safe) wenn sie keine Seiteneffekte haben, also den Zustand des Servers nicht verändern. Siehe dazu auch https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.1 oder https://www.it-swarm.com.de/de/http/was-ist-idempotenz-bei-http-methoden/833267138/. Von den in RFC 7231 definierten Anforderungsmethoden sind die Methoden GET, HEAD, OPTIONS und TRACE als sicher definiert. Als Beispiel dient das Abrufen eines Webseiteninhaltes mit GET. Dabei verändert sich der Zustand der Seite auf dem Server nicht, lediglich Logginginformationen fallen dort zusätzlich an. Logging gilt in diesem Zusammenhang nicht als Seiteneffekt.

Suchmaschinen beispielsweise crawlen das Internet über HTTP-GET-Aufrufe. Lösch- oder Erzeugungsoperationen sollten somit niemals über GET (also einfache Links im Browser) initiiert werden! Erstellt man selber die Software für einen Webserver, darf also die Funktion zur Bearbeitung einer GET-Anfrage niemals etwas am Datenbestand auf dem Server verändern. Für professionelle Webserver wie Apache oder nginx ist das selbstverständlich. Schreibt man den Code dafür selbst, wäre eine fehlerhafte Semantik Auslöser für einen nicht sicheren GET-Befehl.

Eine Operation ist dann idempotent, wenn ein mehrmaliges Aufrufen die gleichen Seiteneffekte hat wie ein einmaliges. https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2. Ein POST-Request wäre nicht idempotent, da er mit jedem Aufruf eine weitere neue Ressource (Datensatz) erzeugt, Hingegen ändert ein zweites Ausführen eines GET, PUT oder DELETE nichts am Zustand des Systems. Zum Beispiel kann ein DELETE auf die URL http://buchshop.de/buecher/123 dieses Buch aus dem Bestand löschen, jedoch würde bei einem zweiten Aufruf dieser URL mit DELETE kein anderes Buch gelöscht werden. Lediglich die Rückmeldung 204 NO_CONTENT würde anzeigen, dass diese Ressource bereits nicht mehr vorhanden ist.

Eine Operation ist cachable, wenn das Ergebnis des Requests für einen definierten Zeitraum zwischengespeichert werden kann, ohne von der ursprünglichen Quelle gelesen werden zu müssen. Die Stärke des Internets liegt auch an der Fähigkeit, Informationen - beispielsweise in Proxies - zwischenzuspeichern (Cache). Alle GET-Requests müssen die Möglichkeit bieten, und nur abgelaufene Ressourcen neu laden.

Repräsentationen
In der Regel erhalten wir bei HTTP-GET Requests im Internet HTML-Seiten als Antwort. Im Rahmen von REST-Services bietet sich aber die Möglichkeit, Ressourcen auf unterschiedliche Art darzustellen. Um auf das Buch-Beispiel zurückzukommen:

Bücher können im Internet unterschiedlichste Repräsentationen haben: als Text (Titel), als XML-Datei, als Bild (Cover), als JSON, als PDF, als MP3 (Hörbuch)...
REST gibt uns die Möglichkeit, bei jedem Aufruf der immer gleichen Ressource, die gewünschte Repräsentation über den Content-type zu wählen.

Literatur

REST Web Services Fachartikel: https://www.oio.de/public/xml/rest-webservices.htm

Suchen Sie auf LinkedIn/learning nach "REST-Grundprinzip verstehen" und schauen Sie sich das Video an