Backend. Hochschule Darmstadt, Fachbereich Informatik, Wintersemester 2016/2017. Christopher Dörge, Thomas Sauer, David Müller

Größe: px

Ab Seite anzeigen:

Download "Backend. Hochschule Darmstadt, Fachbereich Informatik, Wintersemester 2016/2017. Christopher Dörge, Thomas Sauer, David Müller"

Bernt Schmid
vor 6 Jahren
Abrufe

1 Backend Hochschule Darmstadt, Fachbereich Informatik, Wintersemester 2016/2017 Christopher Dörge, Thomas Sauer, David Müller

2 Aufbau einer RESTful API mit... Ziel node.js, express und MongoDB Symfony und MySQL

3 Agenda API-driven development? Welche Eigenschaften von HTTP werden verwendet? Was ist REST? Wie baut man eine Schnittstelle auf? Wie testet man eine Schnittstelle?

4 Push Server verteilen Daten an ihre Clients Broadcast Systeme Pull Clients fragen beim Server nach Daten Klassische Kommunikation im Web Push & Pull

5 Request Client Server Response Pull

6 API-driven Development

8 HTTP Hyper Text Transfer Protocol

9 Request Client Server Response HTTP HTTP

10 Zustandslos Medienunabhängig Verbindungslos Eigenschaften von HTTP

11 port query protocol host resource path HTTP - Request Client Request Response Server

12 GET POST PUT DELETE Request HTTP - Verben Client Response Server

13 GET POST PUT DELETE PATCH Request HTTP - Verben Client Response Server

14 GET POST PUT DELETE PATCH HEAD OPTIONS TRACE CONNECT Request HTTP - Verben Client Response Server

15 GET /path/to/resource?hello=world HTTP/1.1 Host: localhost:80 Cache-Control: no-cache Request Client Server HTTP - Request Response

16 GET /path/to/resource?hello=world HTTP/1.1 Host: localhost:80 Cache-Control: no-cache Request Client Server HTTP - Request Response

17 GET /path/to/resource?hello=world HTTP/1.1 Host: localhost:80 Cache-Control: no-cache Request Client Server HTTP - Request Response

18 POST /path/to/resource HTTP/1.1 Host: localhost:80 Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache hello=world Request Client Server HTTP - Request Response

19 POST /path/to/resource HTTP/1.1 Host: localhost:80 Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache hello=world Request Client Server HTTP - Request Response

20 HTTP/ OK Content-Length: 1167 Content-Type: text/html; charset=utf-8 Date: Thu, 06 Oct :15:00 GMT Last-Modified: Mon, 03 Oct :30:00 GMT <!DOCTYPE html>... Request Client Server HTTP - Response Response

21 Request line Status line POST /path/to/resource HTTP/1.1 Host: localhost:80 Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache hello=world HTTP/ OK Content-Length: 1167 Content-Type: text/html; charset=utf-8 Date: Thu, 06 Oct :15:00 GMT Last-Modified: Mon, 03 Oct :30:00 GMT <!DOCTYPE html>... Request Client Server HTTP - Vergleich Request / Response Response

23 REST

24 Ursprünglich aus einer Dissertation von Roy Fielding (2000) Representational State Transfer Bestimmt eine Reihe von 4 Constraints, die bei einer Client-Server Kommunikation immer gelten sollten (Regeln für den Server) REST

25 Client Server Constraint Request Client Server Response

26 Stateless Server Constraint Server Request Client Server Response Server

27 Caching Constraint Request Client Server Response

28 Uniform Interface Constraint Jedes Interface der API funktioniert auf die gleiche Art und Weise Vier Regeln, die den Aufbau einer RESTful API bestimmen

29 Uniform Interface Constraint - Resources Resources sind die Entitäten der Schnittstelle Uniform Interfaces sind für Dinge (Resourcen) gebaut, nicht für Aktionen (authorize)

30 Uniform Interface Constraint - Verbs GET POST DELETE PUT PATCH

31 Uniform Interface Constraint - Self-descriptive messages Jede Nachricht eines Servers an den Client enthält alle Informationen, die zur Darstellung der Nachricht notwendig sind. Dies inkludiert unter Anderem den notwendigen Parser für den MIME-Type (image/png, application/json, )

32 Uniform Interface Constraint - HATEOAS Hypermedia as the Engine of Application State Actions, die der Client ausüben kann, werden ihm vom Server vorgegeben Bsp: Hyperlinks in Hypertext Der Client sollte über diese Form beim Navigieren durch das System auf alle Ressourcen Zugriff erhalten und nicht raten müssen Dies gilt jedoch nicht für die Einstiegspunkte des Systems

33 Aufbau eines Webservice mit node.js

35 JavaScript im Backend?

36 Popularität (Jeder kennt ein wenig JavaScript) Schnelligkeit (V8 von Google) Event Loop (alle I/O operations werden asynchron im Single Thread ausgeführt) Auch deine DB könnte JavaScript verwenden (MongoDB, RethinkDB) JSON als universelles Datenformat über alle Instanzen Tooling Eine riesige Community JavaScript im Backend?

37 Node Package Manager (npm)

38 Node Package Manager (npm) npm publish reusable-code

39 Node Package Manager (npm) npm install reusable-code

1", "description": "An example module to illustrate the usage of a package.

40 Node Package Manager (npm) npm init reusable-code.js package.json { "name" : "reusable-code", "version": "10.3.1", "description": "An example module to illustrate the usage of a package.json", "author": "Your Name <you.name@example.org>", "contributors": [{ "name": "John Doe", " ": "john.doe@example.com" }], "main": "reusable-code.js", "dependencies" : { "foo" : "1.0.0", "bar" : ">=1.0.2 <2.1.2", }, "license": "MIT" }

41 Node Package Manager (npm)

42 express Web Framework für node.js

43 Zusatz

44 WHAT API - Kommunikation von einem gegebenen System mit einem Fremdsystem WHY Modularität, Aufteilen von Verantwortlichkeiten, Verstecken interner Komplexitäten HOW Davon handelt dieser Foliensatz API-driven Development

45 Zustandslosigkeit Anfragen bilden eine unabängige Transaktion Anfragen werden ohne Bezug auf frühere Anfragen behandelt Medienunabhängig Jede Art Daten kann per HTTP übertragen werden Sowohl Client als auch Server müssen mit Inhalt umgehen können (MIME-Type) Verbindungslosigkeit Client erzeugt HTTP-Request, versendet diesen und bricht Verbindung zum Server ab Server verarbeitet den Request, erzeugt einen Response und verschickt diesen, indem er die Verbindung erneut aufbaut Eigenschaften von HTTP

46 Verbindungslos, aber... Anfragen und Antworten werden per TCP/IP verschickt Verbindungen werden abgebrochen, um Server nicht zu blockieren Nach jedem Verbindungsaufbau wird direkt abgebrochen erzwungene Verbindungslosigkeit Application-Layer Protocol Wird auf Applikationsebene benutzt (Browser/Webserver) Nutzt die Transport-Ebene (Transport Layer) Eigenschaften von HTTP

47 GET - Anfrage einer Ressource (Parameter über Query der URL) POST - Erzeugen einer Ressource (Parameter per HTTP-Body (Payload)) PUT - Erneuern einer Ressource (HTTP-Body enthält Update-Parameter) PATCH - Ändert eine Ressource ohne diese (wie bei PUT) zu ersetzen DELETE - Löschen einer Ressource HEAD - Server sendet Response wie bei GET, nur ohne Content TRACE - Liefert die Anfrage, wie sie vom Server empfangen wurde (wichtig für Debugging) OPTIONS - Liefert Serverfähigkeiten CONNECT - Aufbau eines SSL-Tunnels (nur SSL) HTTP - Verben Client Request Response Server

48 Aufbau nach HTTP-Spezifikation: Request-Line (Client) GET /path/to/resource HTTP/1.1 Status-Line (Server) HTTP/ OK HTTP - Request / Response

49 Existenz eines Clients und eines Servers Client sendet Anfragen (Request) an den Server Server sendet dem Client eine Antwort (Response) REST - Client Server Constraint

50 Server sind zu jeder Zeit austauschbar Somit dürfen keine Clientinformationen auf dem Server gespeichert werden Das Constraint besagt, dass alle relevanten Informationen über den Zustand bei der Kommunikation übertragen werden Alle Informationen für den Server sind im Request Alle Informationen für den Client sind in der Response REST - Stateless Server Constraint

51 Daten, die sich nicht häufig ändern, sollen auch nicht ständig abgefragt werden Deswegen soll der Server dem Client mitteilen, wie lange die Daten noch Gültigkeit besitzen REST - Caching Constraint

52 Die bei der Ausführung der Aktivität eingesetzten HTTP-Verbs diktieren die auszuführende Aktion GET - Daten erhalten POST - Daten hinzufügen DELETE - Datensatz löschen PUT - Datensatz verändern oder ersetzen PATCH - Datensatz partiell verändern REST - Uniform Interface Constraint Verbs

Ähnliche Dokumente

Architektur von REST basierten Webservices

28.11.2005 Architektur von REST basierten Webservices Referent MARK ALTHOFF REST was invented by ROY T. FIELDING and RICHARD N. TAYLOR Geschichtlicher Hintergrund von REST 1994-1995 taucht der Begriff