Webservices und Client Server Konzepte

Zu allererst soll geklärt werden, was ein Webservices ist:

Ein Webservice (auch Webdienst) stellt eine Schnittstelle für die Maschine-zu-Maschine- oder Anwendungs-Kommunikation über Rechnernetze wie das Internet zur Verfügung. Dabei werden Daten ausgetauscht und auf entfernten Computern (Servern) Funktionen aufgerufen. Jeder Webservice besitzt einen Uniform Resource Identifier (URI), über den er eindeutig identifizierbar ist, sowie je nach Implementierung eine Schnittstellenbeschreibung in maschinenlesbarem Format (als XML-Artefakt, z. B. WSDL), die definiert, wie mit dem Webservice zu interagieren ist. Die Kommunikation kann über Protokolle aus dem Internetkontext wie HTTP oder HTTPS erfolgen; über diese Protokolle wiederum kann beispielsweise XML oder JSON übertragen werden. Ein Webservice ist plattformunabhängig und steht in der Regel mehreren Programmen zum Aufrufen bereit. [1]

Was bedeutet dies nun ganz stark vereinfacht. Ein Webservice ist ein Programm, welches auf einem Server läuft, der über das Internet erreichbar ist. Ein Client (Browser, Anwendung, App), sendet Anfragen an diesen Webservice mit einem standardisierten Protokoll (z.B.: HTTP) und erhält darauf Antworten.

Im folgenden wollen wir uns nun mit RESTful Webservices beschäftigen, diese erfreuen sich großer beliebtheit und stehen in Konkurrenz zu anderen Varianten wie z.b.:

• WSDL/Soap basierten Webservices - Stark antiquiertes Konezpt
• GraphQL basierten Webservices - Damit werden unzulänglichkeiten bei RESTful Webservices behoben, jedoch wird auch auf die einheitliche Schnittstelle verzichtet

RESTful Webservice

Ein RESTful Webservice ist nicht eine konkrete Implementierung, es sind vielmehr Prinzipien und Eigenschaften die auf einen Webservice zutreffen müssen, damit es sich um einen RESTful Webservice handelt bzw. einen Webservice der auf den REST Prinzipien beruht. REST steht für Represential State Transfer und wurde von Roy Fielding "entwickelt".

Prinzipien

Im folgenden wollen wir auf einige der Prinzipien eingehen. Folgender Abschnitt ist jedoch nicht vollständig, soll aber an dieser Stelle ausreichen.

Einheitliche Schnittstelle

Dies ist ein Hauptunterscheidungsmerkmal zu den meisten anderen Webservice Architekturen.
Wir sprechen hier von Ressourcen die einheitlich manipuliert, abgerufen und identifiziert werden können. Eine Ressource kann z.B. ein Kundenprofil sein.

Addressierbarkeit von Ressourcen

Jede Ressource hat einen eindeutigen Bezeichner und ist über eine URL erreichbar ist

Kunde mit der id 101 -> https://webservice.drlue.at/customer/101

Selbstbeschreibende Nachrichten

REST Nachrichten sollen selbstbeschreibend sein, dafür sollen Standardmethoden verwendet werden, meist werden hier die HTTP Methoden verwendet.
Betrachten wir das Beispiel des Kunden mit der Id 101 und stellen den Vergleich zu den HTTP Methoden her:

HTTP Methode	URL	Operation
GET	https://webservice.drlue.at/customer/101	Holen der Benutzerinformation
DELETE	https://webservice.drlue.at/customer/101	Löschen des Benutzers
PUT	https://webservice.drlue.at/customer/101	Verändern des Benutzers, es müssen die zu ändernden Daten mitgesendet werden
POST	https://webservice.drlue.at/customer	Anlegen eines neuen Benutzers, die Benutzerdaten müssen mitgesendet werden

Caching

HTTP Caching soll implementiert werden. Wobei jede Anfrage die nicht gestellt werden muss, die beste ist.

Klären wir zuerst den Begriff des Cachings. Dieses Konzept gilt natürlich in vielen Bereichen der Informatik, wir erklären den Begriff anhand des Zugriffs auf eine Ressource. Eine Ressource wird geholt, zu einem späteren Zeitpunkt wird diese Ressource erneut geholt. Hat sich diese nicht verändert, so soll sie nicht erneut übertragen werden, sondern aus dem Zwischenspeicher der Anwendung abgerufen werden.

Durch Caching bei Webanwendungen soll die Übertragung von Daten über das Internet reduziert werden.

In folgender Tabelle wird die Funktionsweise von HTTP Caching mittels ETag beschrieben. Man beachte, die HTTP Anfragen sind nicht vollständig und beschränken sich auf die fürs Caching wesentlichen Header.

Ablauf beim Anfragen auf eine Ressource (http://webservice.drlue.at/customer/101)

Anfrage	Antwort	Beschreibung
GET /customer/101 HTTP/1.1 Host: webservice.drlue.at	HTTP/1.1 200 OK Etag: "478fb2348f700" { "name": "luke", "id": 101 }	Erstmaliges holen der spezifischen Ressource. Server Antwortet mit den Daten und liefert im HTTP Header den ETag mit
GET /customer/101 HTTP/1.1 Host: webservice.drlue.at If-none-match: "478fb2348f700"	HTTP/1.1 304 Not Modified Etag: "478fb2348f700"	Eine weitere Anfrage des Clients erfolgt mit dem ETag nun aber im If-none-match Header. Man könnte diese Anfrage wie folgt interpretieren: Gib mir die Ressource nur zurück, wenn der ETag nicht mehr zutrifft. Der Server Antwortet mit dem HTTP Statuscode 304 Not Modified. Dies bedeutet, es hat sich nichts geändert. Der Client wird somit darauf hingewiesen die Daten aus seinem eigenen Cache oder Zwischenspeicher zu holen.
GET /customer/101 HTTP/1.1 Host: webservice.drlue.at If-none-match: "478fb2348f700"	HTTP/1.1 200 OK Etag: "497fb2348f705" { "name": "luke1", "id": 101 }	Zu einem späteren Zeitpunkt holt der Client erneut die Selbe Ressource und sendet wieder den ETag mit. Die Ressource hat sich jedoch am Server geändert. Dieser sendet die Ressource dem Client zurück und sendet zusätzlich im Header den neuen ETag mit.

Mögliche Implementierung

In modernen Technologien wie z.B.: Express für Node.js finden sich automatische mechanismen für die Caching implementierung über ETags. Der Ablauf ist denkbar einfach. Der Server betrachtet vor dem Absenden der Antwort an den Client deren Inhalt. Es geht hier nur um den HTTP Body, die Header spielen hier keine Rolle. Aus dem Body wird eine Hashsumme berechnet und diese wird dann als ETag verwendet.

Hashsumme: Mittels eines Hashalgorithmus wie z.b.: (SHA256, MD5, ...) kann aus einer großen Datenmenge ein "eindeutiger" Wert berechnet werden. Bei SHA256 hat dieser Wert immer eine Länge von 256 Bit, egal wie groß der Input ist. Der Wert kann natürlich nicht eindeut sein, doch die Chance ist verschwindend gering, dass für unterschiedliche Input Daten, die selbe Hashsumme gebildet wird.

Diese Implementierung bietet eine einfache Möglichkeit des Cachings um die Datenübertragung vom Client zum Server deutlich zu reduzieren. Die Reduziert die Netzwerklast auf Client und Serverseite.
Eine Rechenauslastung auf Seiten des Servers findet jedoch nicht statt. Der Body der Antwort muss bei jeder Antwort erstellt werden um den ETag zu erstellen. Das bedeutet, der Server muss trotzdem Anfragen an die Datenbank stellen bzw. alle nötigen Berechnungen ausführen um die Antwort zu erstellen.