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

Präsentation zum Thema: "© WZL/Fraunhofer IPT Eine Gegenüberstellung von Websockets und RESTful Web Services Seminarvortrag von Lucie Mades."—  Präsentation transkript:

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

2 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

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

4 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

5 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, …)

6 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

7 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

8 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

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

10 Seite 10© WZL/Fraunhofer IPT REST: Polling

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

12 Seite 12© WZL/Fraunhofer IPT REST: Streaming

13 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

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

15 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

16 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

17 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/1.1 101 Switching Protocols Upgrade: WebSocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= (…) Client Server

18 Seite 18© WZL/Fraunhofer IPT Websockets: Message Framing Extended Payload length continued (if payload len == 127) RSV1RSV1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 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

19 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

20 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:

21 © WZL/Fraunhofer IPT Fazit

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