Backend Hochschule Darmstadt, Fachbereich Informatik, Wintersemester 2016/2017 Christopher Dörge, Thomas Sauer, David Müller
Aufbau einer RESTful API mit... Ziel node.js, express und MongoDB Symfony und MySQL
Agenda API-driven development? Welche Eigenschaften von HTTP werden verwendet? Was ist REST? Wie baut man eine Schnittstelle auf? Wie testet man eine Schnittstelle?
Push Server verteilen Daten an ihre Clients Broadcast Systeme Pull Clients fragen beim Server nach Daten Klassische Kommunikation im Web Push & Pull
Request Client Server Response Pull
API-driven Development
https://www.getpostman.com/
HTTP Hyper Text Transfer Protocol
Request Client Server Response HTTP HTTP
Zustandslos Medienunabhängig Verbindungslos Eigenschaften von HTTP
port query http://www.domain.com:1234/path/to/resource?a=b&x=y protocol host resource path HTTP - Request Client Request Response Server
GET POST PUT DELETE Request HTTP - Verben Client Response Server
GET POST PUT DELETE PATCH Request HTTP - Verben Client Response Server
GET POST PUT DELETE PATCH HEAD OPTIONS TRACE CONNECT Request HTTP - Verben Client Response Server
http://localhost:80/path/to/resource?hello=world GET /path/to/resource?hello=world HTTP/1.1 Host: localhost:80 Cache-Control: no-cache Request Client Server HTTP - Request Response
http://localhost:80/path/to/resource?hello=world GET /path/to/resource?hello=world HTTP/1.1 Host: localhost:80 Cache-Control: no-cache Request Client Server HTTP - Request Response
http://localhost:80/path/to/resource?hello=world GET /path/to/resource?hello=world HTTP/1.1 Host: localhost:80 Cache-Control: no-cache Request Client Server HTTP - Request Response
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
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
HTTP/1.1 200 OK Content-Length: 1167 Content-Type: text/html; charset=utf-8 Date: Thu, 06 Oct 2016 16:15:00 GMT Last-Modified: Mon, 03 Oct 2016 15:30:00 GMT <!DOCTYPE html>... Request Client Server HTTP - Response Response
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/1.1 200 OK Content-Length: 1167 Content-Type: text/html; charset=utf-8 Date: Thu, 06 Oct 2016 16:15:00 GMT Last-Modified: Mon, 03 Oct 2016 15:30:00 GMT <!DOCTYPE html>... Request Client Server HTTP - Vergleich Request / Response Response
http://todomvc.com/
REST
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
Client Server Constraint Request Client Server Response
Stateless Server Constraint Server Request Client Server Response Server
Caching Constraint Request Client Server Response
Uniform Interface Constraint Jedes Interface der API funktioniert auf die gleiche Art und Weise Vier Regeln, die den Aufbau einer RESTful API bestimmen
Uniform Interface Constraint - Resources Resources sind die Entitäten der Schnittstelle Uniform Interfaces sind für Dinge (Resourcen) gebaut, nicht für Aktionen (authorize) http://.../tasks/
Uniform Interface Constraint - Verbs GET POST DELETE PUT PATCH
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, )
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
Aufbau eines Webservice mit node.js
https://nodejs.org/
JavaScript im Backend?
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?
Node Package Manager (npm) https://www.npmjs.com/
Node Package Manager (npm) npm publish reusable-code
Node Package Manager (npm) npm install reusable-code
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", "email": "john.doe@example.com" }], "main": "reusable-code.js", "dependencies" : { "foo" : "1.0.0", "bar" : ">=1.0.2 <2.1.2", }, "license": "MIT" }
Node Package Manager (npm)
express Web Framework für node.js
Zusatz
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
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
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
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
Aufbau nach HTTP-Spezifikation: https://cdn.tutsplus.com/net/authors/jeremymcpeak/http1-req-res-details.png Request-Line (Client) GET /path/to/resource HTTP/1.1 Status-Line (Server) HTTP/1.1 200 OK HTTP - Request / Response
Existenz eines Clients und eines Servers Client sendet Anfragen (Request) an den Server Server sendet dem Client eine Antwort (Response) REST - Client Server Constraint
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
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
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