JUGTAAS - RESTFULOVVERO,

COME SCOMODARE UN CLOUD RESTFULPER UN LAVORO DA PAGINETTA PHP…

by Tiziano Lattisi

RICETTA• Servizio in cloud di RedHat (OpenShift)

• Versionamento (git su GitHub e OpenShift)

• Tomcat

• Jax-ws (Jersey)

• Json (Jackson)

• AngularJS

OPENSHIFT DI REDHAT

• Gratuito fino a tre applicazioni con tre "small gears" ciascuna

• Repository git

• SSH

• https://www.openshift.com

RICHARDSON MATURITY MODEL

• RMM estende l’approccio REST introducendo :

• Risorse

• Verbi HTTP

• Hypermedia link

REST (RICAPITOLIAMO)• separazione client / server

• stateless: nessun contesto client memorizzato sul server (Representational State Transfer)

• cacheable: i client possono fare cache delle risposte

• layered: posso metterci in mezzo load balancing, cache, etc

• code on demand (opzionale): es. il server può passare codice js

• uniform interface: identificazione risorse, manipolazione attraverso la rappresentazione, messaggi auto-descrittivi, hateoas

HTTP COME TRASPORTO

• HTTP semplicemente come tunnel

• Nessun altro meccanismo tipico del web

• URI rappresentano servizi (come soap, xml-rpc)

• Architetture SOA (services oriented architecture)

POST /eventsService HTTP/1.1 {“request”: “get”, ”event-id”: 3}

HTTP/1.1 200 OK {“title”: “...”, “description”: “...”, “status”: “pending”}

POST /eventsService HTTP/1.1 {“request”: “confirm”, ”event-id”: 3}

HTTP/1.1 200 OK {“title”: “...”, “description”: “...”, “status”: “confirmed”}

RISORSE

• URI rappresentano risorse

• I “metodi” vengono chiamati sulle risorse

• Architettura ROA (resources oriented architecture)

POST /events/3 HTTP/1.1 {“request”: “options”}

HTTP/1.1 200 OK {“options”: [ {“id”: 123, “date”: “2015-03-19”, “hour”: “18:00”}, {“id”: 124, “date”: “2015-03-19”, “hour”: “19:00”} ]}

POST /options/123 HTTP/1.1 {“request”: “confirm”, “participant”: “Tiziano”}

HTTP/1.1 200 OK {“id”: 123, “participant”: “Tiziano”, “status”: “confirmed”}

HTTP VERBS

• I verbi HTTP per il controllo del ciclo di vita della risorsa (CRUD)

• Utilizzo dei codici di risposta HTTP

• Rispetto dei comportamenti safe e idempotent dei verbi HTTP

• Safe: la chiamata non comporta modificazioni sul server

• Idempotent: chiamate successive alla prima non comportano modificazioni sul server

(almeno per quanto il client possa percepire)

SAFE AND IDEMPOTENTsafe idempotent verb ex. codes

Select v v GET 200 OK

Insert x x POST 201 Created

Update/Insert x v PUT 204 No content

Partial update x x PATCH 204 No content

Delete x v DELETE 200 OK

Client errors: 4xx (400 Bad request, 401 Unauthorized, 404 Not found,…)

Server errors: 5xx

GET /events/3 HTTP/1.1

HTTP/1.1 200 OK {“id”: 3, “title”: “...”, “description”: “...”, “status”: “confirmed”}

POST /events HTTP/1.1 {“title”: “...”, “description”: “...”}

HTTP/1.1 201 CREATED {“id”: 4, “title”: “...”, “description”: “...”, “status”: “pending”}

HYPERMEDIA CONTROLS

• HATEOAS (hypermedia as the engine of application state)

• La risorsa espone dei link che indicano come proseguire nell’interazione con la risorsa stessa

GET /events?filterBy=confirmed&startIndex=4&size=4 HTTP/1.1

HTTP/1.1 200 OK { “events”: { “0”: “/services/events/1”, “1”: “/services/events/12” }, "_links": { “self”: “/events?filterBy=confirmed&startIndex=4&size=4”, “prev”: “/events?filterBy=confirmed&startIndex=0&size=4”, “next”: “/events?filterBy=confirmed&startIndex=8&size=4”, } }

GET /events/1 HTTP/1.1

HTTP/1.1 200 OK { “title”: “A new talk”, “description”: “An interesting talk” “events”: { “0”: “/services/events/1”, “1”: “/services/events/12” }, "_links": { “self”: “/events/1”, “confirm”: “/events/1/confirm”, “post-resource”: “/resources/1”, } }

FLUSSO GIT

master

develop

v. 1.0 v. 2.0

masterv. 1.0 v. 2.0

GITHUB

OpenShift

build & deploy handle

VEDIAMO UN PO’ DI COSE• API: services-jugtaas.rhcloud.com/docs/swagger-ui/?url=../api/services.json

• Configurazione Tomcat OpenShift da git:

• https://github.com/jugtaas/services/blob/develop/.openshift/config/server.xml

• https://github.com/jugtaas/services/blob/develop/src/main/webapp/WEB-INF/web.xml

• Backports ZoeXF:

• https://github.com/jugtaas/services/blob/develop/src/main/java/org/jugtaas/services/zoefxports/rest/AbstractResource.java

• https://github.com/jugtaas/services/blob/develop/src/main/java/org/jugtaas/services/zoefxports/db/Manager.java

NOTE• Abbiamo usato json, che non ha hypermedia support (json-ld

oppure hal); non abbiamo usato xhtml/atom per AngularJs

• PUT (idempotent) o POST (!idempotent)?

• Risorse composite (buona idea per la cache):/events/3/speakers

• Autenticazione/autorizzazione su ogni richiesta

• Backport da ZoeFX per manager jpa e hateoas

RISORSE• Roy Fielding (tesi di dottorato, idea originale di REST): http://

www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm

• Martin Fowler (articolo RMM): http://martinfowler.com/articles/richardsonMaturityModel.html

• http://www.w3.org/TR/json-ld/

• http://stateless.co/hal_specification.html

• https://github.com/jugtaas/services

E ora passiamo al client…