Resource Oriented Architecture

66
Page 1 Ressource Oriented Architecture L’architecture du Web et le REST

description

Resource Oriented Architecture, Symposium DNG

Transcript of Resource Oriented Architecture

Page 1: Resource Oriented Architecture

Page 1

Ressource Oriented ArchitectureL’architecture du Web et le REST

Page 2: Resource Oriented Architecture

Aurélien PelletierArchitecte Logiciel

Expertise Java

En charge de la veille technologique Web 2.0 au sein du département innovation d’Atos Origin

http://blogpro.toutantic.net

Qui ?

Page 2

Page 3: Resource Oriented Architecture

Page 3

Objectifs

Comprendre le style d’architecture REST

Comprendre les différences entre service et ressource

Page 4: Resource Oriented Architecture

Page 4

Agenda

L’architecture des Mash-UpCrée une application RESTful L’architecture orientée ressourceRESTLe débat SOAP/RESTRessources & Services

Page 5: Resource Oriented Architecture

D’un Web de pages

Page 6: Resource Oriented Architecture

A un web de Ressources

Page 7: Resource Oriented Architecture

Mash-up

Page 8: Resource Oriented Architecture

L’approche

Style d'architecture

Architecture

Technologies

REST

HTTP URIXML

Ab

straction

Ab

straction

( Web 2.0)ROA

Technologies

Page 9: Resource Oriented Architecture

Crée une application RESTful

Page 10: Resource Oriented Architecture

Page 10

http://dng.org/symposium/2008/

http://dng.org/symposium/2008/sessions

http://dng.org/symposium/2008/sessions/ROA

http://dng.org/symposium/2008/speakers/aurelien

http://dng.org/symposium/2008/participants/

1 Donner un identifiant unique à toutes les choses intéressantes ou Donner une URI à toutes les ressources

Page 11: Resource Oriented Architecture

Page 11

2 Permettre plusieurs représentations

GET http://dng.org/symposium/2008/sessions/day1Accept : text/html

Représentation

Page 12: Resource Oriented Architecture

Page 12

<sessions><date>11/02/2008</date><session id="1">

<time></time><name>Session Plénière</name><summary>

Environnements Web, développement logiciel, recherche et développement. Tels sont quelques uns des sujets qui seront démontrés.

</summary></session>

GET http://dng.org/symposium/2008/sessions/day1Accept : application/xml

2 Permettre plusieurs représentations

Représentation

Page 13: Resource Oriented Architecture

Page 13

<sessions><date>11/02/2008</date><session id="1">

<name>Session Plénière</name></session>

GET http://dng.org/symposium/2008/sessions/day1?format=courtAccept : application/xml

2 Permettre plusieurs représentations

Représentation

Page 14: Resource Oriented Architecture

Page 14

<sessions><date>11/02/2008</date><session id="1">

<time></time><name>Session Plénière</name><summary>

Environnements Web, développement logiciel, recherche et développement. Tels sont quelques uns des sujets qui seront démontrés.

</summary></session><session id="5" ref="http://dng.org/symposium/2008/sessions/roa">

<time>16:00 - 17:00</time><name>Resource Oriented Architecture (ROA)</name><summary></summary>

<speaker ref="http://dng.org/symposium/2008/speakers/aurelien"> Aurélien Pelletier</speaker></session>

3 Mettre des liens dans les représentations

Page 15: Resource Oriented Architecture

Page 15

4 Utiliser l'interface uniforme d'HTTP

Page 16: Resource Oriented Architecture

Page 16

GET

GET retourne une représentation de l'état courant d'une ressource

Get est idempotentLa même requête produit à chaque invocation le même résultat sur le serveur.

Ne change pas l'état d'une ressource

Page 17: Resource Oriented Architecture

Page 17

POST crée une nouvelle ressource

C'est le serveur qui décide de l'URI de la nouvelle ressource

POST n'est pas idempotent !

Crée une nouvelle URI

POST

Page 18: Resource Oriented Architecture

Page 18

PUT crée ou modifie une ressource

Dans le cas d'une création c'est le client qui décide de l'URI de la ressource

Change l'état d'une ressourcePUT est idempotent

DELETE efface logiquement la ressource

DELETE est idempotent

PUT & DELETE

Page 19: Resource Oriented Architecture

Page 19

HEAD Obtenir uniquement les entêtes

OPTIONS Liste des méthodes supportées par une ressource

HTML 4 ne supporte que GET et POST

OPTION & HEAD

Page 20: Resource Oriented Architecture

Page 20

Approche services RPC

Calculatrice 4 opérations

Page 21: Resource Oriented Architecture

Page 21

Approche ressources REST

http://calc/soustraction?val1=xx&val2=yy

http://calc/multiplication?val1=xx&val2=yy

http://calc/addition?val1=xx&val2=yy

http://calc/division?val1=xx&val2=yy

Calculatrice 4 opérations

Page 22: Resource Oriented Architecture

Page 22

http://calc/chiffres/1

http://calc/operations/division http://calc/operations/additionhttp://calc/operations/...

http://calc/calculs/

http://calc/nombres/

Approche ressources REST

Calculatrice 4 opérations

Page 23: Resource Oriented Architecture

Page 23

Calculatrice 4 opérations

PUT /nombres/douze HTTP/1.1Host: calc

<nombre><dizaine>http://calc/chiffres/1<dizaine><unite>http://calc/chiffres/2<unite>

</nombre>

201 Created

POST /calculs/ HTTP 1.1Host: calc

<calcul><nombre>http://calc/nombres/douze</nombre><operation>http://calc/operation/addition</operation><nombre>http://calc/nombres/cinq</nombre><calcul>

201 CreatedLocation: http://calc/calculs/UID

<result>17</result>

Requête

Réponse

Page 24: Resource Oriented Architecture

Page 24

Calculatrice 4 opérations

GET /calculs/UID HTTP/1.1Host: calc

200 OK<calcul><nombre>http://calc/nombres/douze</nombre><operation>http://calc/operation/addition</operation><nombre>http://calc/nombres/cinq</nombre><result ref ="http://calc/nombres/resultUID">17</result><calcul>

Page 25: Resource Oriented Architecture

Application RESTful

1 Identifier les ressources

2 Définir les représentations

3 Relier les représentations par des liens

4 Utiliser l’interface uniforme

Page 26: Resource Oriented Architecture

Page 26

Architecture Orientée Ressource

Page 27: Resource Oriented Architecture

4ième génération d'architecture

Net - Ware3 tiers

Client léger

Hard - WareMainframe

Client passif

Soft - WareClient-serverClient lourd

Info - WareROA

Client riche

Page 28: Resource Oriented Architecture

Page 28

Affichage

Construction des écrans

Traitementsmétiers

Données persistantes

Données de sessions

Mainframe / Client passif

Page 29: Resource Oriented Architecture

Page 29

Interface ODBC/JDBC/...

Poste clientBase de données

Client-serveur / Client lourd

Page 30: Resource Oriented Architecture

Page 30

Interface HTTP

NavigateurBase de donnéesServeur d'applications

Interface ODBC/JDBC/...

3 tiers / Client léger

Page 31: Resource Oriented Architecture

Page 31

Interface de services

Ressources

Client richeServeur d'applications

ROA / Client riche

Base de données

Interface ODBC/JDBC/...

Page 32: Resource Oriented Architecture

Page 32

Architecture of the World Wide Web, Volume OneW3C Recommendation 15 December 2004http://www.w3.org/TR/webarch/

Identifiant, ressource, représentation

Page 33: Resource Oriented Architecture

Page 33

Cool URI don't change

L'URI fait partie de l'interface publique

URI are opaque

Utiliser des URI logiques plutôt que physiques:

http://dng.org/symposium/2007/sessions.html

=> Couplage faible

=> Evolutivité

=> Lisibilité

Cool URI don't change

Page 34: Resource Oriented Architecture

Page 34

REST

Page 35: Resource Oriented Architecture

Page 35

Representational State Transfer

REST

Le terme provient de la thèse de Roy Fielding en 2000- principal architecte d'HTTP 1.1- co-auteur de la spécification des URI.

L'appel à GET transfère la représentation d'une ressource. Cette représentation place le client dans un certain état. Suivre un lien va transférer une nouvelle représentation et changer l'état du client.

=> Representational State Transfer

Page 36: Resource Oriented Architecture

Page 36

Representational State Transfer

REST est un style d'architecture

Un style d'architecture est un ensemble de contraintes cohérentes qui en limitant un système lui procure des propriétés désirées.

REST capture les principes fondamentauxqui font le succès du Web.

REST décrit les contraintes qui permettent au web d'être simple, performant, fiable, scalable et évolutif

Page 37: Resource Oriented Architecture

Page 37

Envoyer un message sur le réseau

Page 38: Resource Oriented Architecture

Page 38

Principes d'architecture généraux

Page 39: Resource Oriented Architecture

Page 39

Principes d'architecture généraux

Système en coucheCapacité à monter en chargeSécuritéIntégration au legacy

Code à la demande (optionnel)EvolutivitéJavascript => AJAX

Page 40: Resource Oriented Architecture

Interface uniforme

L’interface uniforme (principe de généricité)+ Simplicité+ Evolutivité- Efficacité

Fonctionne avec 4 contraintes complémentaires

Identification des ressources (URI)Manipulation des ressources par des représentationsMessages auto-descriptifL’Hypermedia comme moteur de l’état de l’application

Page 41: Resource Oriented Architecture

Page 41

Le débat: SOAP vs REST

Page 42: Resource Oriented Architecture

Page 42

Objectif

Styled'architecture

Architecture ROA

Technologies

REST

SOAP WSDL UDDI WS-*

HTTP URIXML

Aligner l'IT sur le métier

Aligner l'IT sur le Web

SOA

RessourcesRessources ServicesServices

++

Ressources et Services

Page 43: Resource Oriented Architecture

Page 43

Technologies SOAP WSDL UDDI WS-*

HTTP URIXML

Les arguments des partisans d’HTTP seul

HTTP vs SOAP

Page 44: Resource Oriented Architecture

Page 44

Web Services = SOAP + WSDL + UDDI +WS-*

Où est le Web dans ces Web Services ?

- Mauvaise utilisation du protocole HTTP

- Pas d'URI

Il faut trouver un autre nom

Big Web Services vs Light Web Services

Un service web léger est un site web navigable par les machines

Web Services ?

Page 45: Resource Oriented Architecture

Page 45

WS-* est trop complexeCe sont les « big vendors » qui ont inventé et poussent SOAP / WS-*

Page 46: Resource Oriented Architecture

Page 46

SOAP WS-* => Design by commitee Interopérabilité moyenne

REST s'appuie sur des standards existant et largement répandu: Identification des ressources URI Transport et l'interface générique HTTP Représentations HTML , XML, gif, ...

Type Mime

Des clients HTTP et des parseurs XML de qualité sont disponibles pour tous les langages Véritable Interopérabilité

SOAP/WS-* sont les DRM de la SOA, HTTP en est le MP3.

Interopérabilité

Page 47: Resource Oriented Architecture

Page 47

Technologies SOAP WSDL UDDI WS-*

HTTP URIXML

Les arguments des partisans de SOAP

HTTP vs SOAP

Page 48: Resource Oriented Architecture

Page 48

SOAP/WS-* HTTPProtocole d'interaction SOAP HTTP

Protocole de transport HTTP ou autre HTTP

Description des interfaces WSDL WADL

Sécurité

ReliableMessaging WS-Reliability Idempotence

Transaction distribuée WS-AtomicTransaction

YAGNIPolicy WS-Policy

Business process BPEL

WS-SecurityWS-TrutsWS-SecureConversation

SSLBasic/Digest Auth

Fonctionnalités avancées

Page 49: Resource Oriented Architecture

Page 49

Conversation machine to machine

HTTP + XML fonctionne très bien pour les échanges Humain/serveur au travers d'un navigateur.

SOAP/WS-* est plus adapté pour des échanges bidirectionnels entre composants serveur machine to machine.

Page 50: Resource Oriented Architecture

Page 50

Styled'architecture

Architecture ROA

RESTSOA

REST-ROA / SOA

Page 51: Resource Oriented Architecture

Page 51

REST-ROA / SOA

REST/ROA Un travail théorique de référence (thèse de Fielding)

Une architecture: celle définie par le W3C

Une implémentation: le Web

Des principes et des contraintes d'architectures bien définis

Approche bottom-up

Hérite de la culture du Web

SOAEnglobe le style d'architecture et les architectures

Pas de contraintes d'architectures ou de principe universellement reconnus

Approche bottom-up

Hérite de la culture Entreprise et RPC/CORBA/DCOM

Page 52: Resource Oriented Architecture

Page 52

RessourcesRessources ServicesServices

Ressources et Services

Page 53: Resource Oriented Architecture

Page 53

Une seule interface uniforme générique

Plusieurs interfaces spécialisées

VerbesNoms

Services

Ressources

Orienté données

Plus de possibilités de réutilisationMoins de contrôlePlus de simplicité

Ressources et Services

Orienté traitement

Meilleure efficacitéPlus de contrôlePlus de complexité

Page 54: Resource Oriented Architecture

Page 54

Accéder à une donnée avec un service?

getFacture(Identifiant)

serialization/deserialization XML

Accéder à un traitement avec une ressource?

Une ressource est une abstraction on peut mapper un traitement sur une ressource.

Ce n'est pas toujours pertinent (service de conversion de température)

En mappant un traitement sur une ressource on lui donne une URI (utile pour retrouver une commande)

Il faut faire de l'URI design nouvelle compétence

Ressources et Services

Page 55: Resource Oriented Architecture

Page 55

Traitements

Données

Backend

Frontend

Ressources et Services

ServicesSOA SOAP/WS-*

ServicesSOA SOAP/WS-*

RessourcesREST HTTP

RessourcesREST HTTP

Page 56: Resource Oriented Architecture

Page 56

procéduralprocédural

ObjetObjet

ServiceService ServiceService

procéduralprocédural

ObjetObjet

procéduralprocédural procéduralprocédural

ObjetObjet

RessourceRessource

Softwares + Services + Ressources

Page 57: Resource Oriented Architecture

Page 57

“25% des solutions d'entreprises à travers le monde seront distribuées sous la forme Software as a Service d'ici 2011”

Fin du débat propriétaire VS open source

Importance du lock-in par les données.

L'important est/sera la portabilité des données

Open Data

Softwares + Services + Ressources

Page 58: Resource Oriented Architecture

Page 58

Intéropérabilité (HTTP + XML) + Adressabilité (URI)

Surface de contact plus grande avec les applications

Favorise la sérendipité (serenpidity)

« L'art de faire une découverte intéressante en cherchant autre chose »

Donc l'innovation

Innovation

Page 59: Resource Oriented Architecture

Page 59

Restafarians ?

Page 60: Resource Oriented Architecture

Page 60

La bible

Page 61: Resource Oriented Architecture

Page 61

Le nouveau testament

Page 62: Resource Oriented Architecture

Page 62

Les apôtres

Pete Lacey http://wanderingbarque.com/nonintersecting/

Stefan Tilkov http://www.innoq.com/blog/st/

Bill de Hora http://dehora.net/journal/

Mark Baker http://www.markbaker.ca

Steve Vinoski http://steve.vinoski.net/blog/

Stuart Charlton http://www.stucharlton.com

...

YOU ?

Page 63: Resource Oriented Architecture

Page 63

Conclusion

4ième génération d'architecture

Softwares + Services + Ressources

Open Data

L'approche orienté ressources + interface uniforme est l’un des moteurs de l'innovation sur le Web

Page 64: Resource Oriented Architecture

- IstockPhoto pour les photos

- Le projet Crystal pour les icônes

- Mes collègues d'Atos Origin pour leurs retours critiques

Remerciements

Page 65: Resource Oriented Architecture

Page 65

Annexes

Page 66: Resource Oriented Architecture

Page 66

HTTP ne garanti pas la livraison d'un message

Mais GET/PUT/DELETE sont idempotent

On peut renouveler l'appel jusqu'à obtenir une réponse

Problème avec POST

Utiliser une « ressource factory » pour obtenir une url pointant vers une ressource « vide »

Utiliser PUT

Comment gérer la fiabilité en HTTP