© WZL/Fraunhofer IPT Eine Gegenüberstellung von Websockets und RESTful Web Services Seminarvortrag von Lucie Mades

Seite 2© WZL/Fraunhofer IPT Gliederung RESTful Web Services –Der REST Architekturstil –Web Services –RESTful Web Services –Vor- und Nachteile Websockets –Generelle Idee –Das Websocket-Protokoll –Implementierung –Vor- und Nachteile Fazit

© WZL/Fraunhofer IPT RESTful Web Services –Der REST Architekturstil –Web Services –RESTful Web Services –Vor- und Nachteile

Seite 4© WZL/Fraunhofer IPT REST: Der REST-Architekturstil REpresentational State Transfer Strukturierung verteilter Systeme –Besonders: Web Services im Internet Grundgedanke: Netzwerkkommunikation erleichtern durch ausgewählte Einschränkungen Bedingungen an eine REST-Anwendung –Einheitliche Schnittstelle –Adressierbarkeit –Zustandslose Kommunikation –Schichtensystem –Verbindungshaftigkeit

Seite 5© WZL/Fraunhofer IPT REST: Der REST-Architekturstil Ressourcen –Informationen aller Art –Erreichbar über eindeutige Adresse –Bearbeitung durch einfaches Set einheitlicher Methoden: GET, PUT, POST, DELETE –Verweise auf andere Ressourcen (Verbindungshaft) Repräsentationen –Den Anforderungen entsprechend –Verschiedene Repräsentationen für die gleiche Ressource –Vordefinierte Formate (HTML, XML, JPG, …)

Seite 6© WZL/Fraunhofer IPT 1 1 M=0,0;R=1 (1,0);(0,1);(-1,0) x²+y² = 1 … Repräsentationen des KreisesDer Kreis als Figur: REST: Beispiel für verschiedene Repräsentationen einer Ressource x y

Seite 7© WZL/Fraunhofer IPT REST: Web Services Bereitstellung von Diensten über ein Netzwerk Unabhängig vom service provider Klare Schnittstelle –Datenformat –Transportprotokolle plattformunabhägig

Seite 8© WZL/Fraunhofer IPT REST: RESTful Web Services Verwendung etablierter Standards –HTTP –URI –Datenformate: XML, HTML, XHTML, JPG, … Vielseitige Verwendung von Ressourcen –Datenspeicherung –Verwaltung der Daten –Komplexe Aufträge und Antworten Anwendung = geschickter Ressourcenaufbau

Seite 9© WZL/Fraunhofer IPT REST: RESTful Web Services HTTP-Methoden: –GETAbfragen –PUTErstellen / überschreiben –POSTAktualisieren –DELETElöschen Beispiel einer Anfrage: GET HTTP/1.1 If-Modified-Since: Fri, 2 Nov :43:31 GMT Synchrone Kommunikation –Server agiert reaktiv –Problem: Echtzeitfähigkeit erfordert regelmäßige Updates –Notlösungen: Polling, Long-Polling und Streaming

Seite 10© WZL/Fraunhofer IPT REST: Polling

Seite 11© WZL/Fraunhofer IPT REST: Long-Polling

Seite 12© WZL/Fraunhofer IPT REST: Streaming

Seite 13© WZL/Fraunhofer IPT REST: Vor- und Nachteile Einfache Verwendung –Einheitliche Schnittstellen –wenige Methoden Flexible Darstellung verwalteter Daten Standardisiert –Kompatibilität –Derzeit meist verbreitetes Modell Einseitige Verbindung –Nur Client kann Nachricht schicken –Lösungen nicht schnell genug Overhead –Hohe Latenz –Netzbelastung Multiple Verbindungen Quelle: Programmable Web

© WZL/Fraunhofer IPT Websockets –Generelle Idee –Das Websocket-Protokoll –Implementierung –Vor- und Nachteile

Seite 15© WZL/Fraunhofer IPT Websockets: Generelle Idee Grundmodell: Socket Asynchrone Kommunikation TCP-Datenstrom über HTTP-Sitzung –Implememtiert als HTTP-Upgrade Ermöglicht Socket-Tunnel über verteilte Netzwerke

Seite 16© WZL/Fraunhofer IPT Websockets: Das Websocket-Protokoll Zwei Hauptbestandteile: –handshake –message framing Eigenes Url-Schema für Server: ws://echo.websocket.org/ bzw. wss://echo.websocket.org/ Erlaubte Nachrichtentypen: –Textdaten –Binärdaten –Control Frames

Seite 17© WZL/Fraunhofer IPT Websockets: Opening Handshake GET /chat HTTP/1.1 Host: server.example.com Upgrade: WebSocket Connection: Upgrade Sec-Websocket-Key: dGhlIHNhbXBsZSBub25jZQ== (…) HTTP/ Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= (…) Client Server

Seite 18© WZL/Fraunhofer IPT Websockets: Message Framing Extended Payload length continued (if payload len == 127) RSV1RSV FINFIN RSV3RSV3 RSV2RSV2 opcode (4) MASKMASK Payload len (7) Extended Payload length (16/64) (if payload len == 126/127) Masking-key (if MASK set to 1) Making-key (continued)Payload Data Payload Data … Quelle: The Websocket Protocol, IETF

Seite 19© WZL/Fraunhofer IPT Websockets: Implementierung: Interface (vereinfacht) [Constructor(DOMString url, optional (DOMString or DOMString[]) protocols)] interface WebSocket{ readonly attribute DOMString url; // networking attribute EventHandler onopen; attribute EventHandler onerror; attribute EventHandler onclose; readonly attribute DOMString extensions; readonly attribute DOMString protocol; void close(); // messaging attribute EventHandler onmessage; void send(DOMString data); void send(Blob data); }; Quelle: The Websocket API, W3C

Seite 20© WZL/Fraunhofer IPT Websockets: Vor- und Nachteile Ersatz für synchrone „Notlösungen“ (Polling, …) Schnellere Verbindung Weniger Overhead –Minimaler Header nur 2 Byte Umgehung von Firewalls und Proxys –Verbindung bildet Tunnel –Aufbau über Standard-Ports Rückstufung auf Kommunikation ohne Standardisierung –Kompatibilität leidet –Keine Einheitlichkeit Quelle:

© WZL/Fraunhofer IPT Fazit

Seite 22© WZL/Fraunhofer IPT Fazit: verschiedene Anwendungsgebiete Websockets: –Echtzeitanwendungen –Einzelne / spezielle Anwendungen –Geringe Latenz Web Services: –Übersichtliche, kompatible Anwendungen –Keine längeren Sessions