Page 1
Ressource Oriented ArchitectureL’architecture du Web et le REST
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
Objectifs
Comprendre le style d’architecture REST
Comprendre les différences entre service et ressource
Page 4
Agenda
L’architecture des Mash-UpCrée une application RESTful L’architecture orientée ressourceRESTLe débat SOAP/RESTRessources & Services
D’un Web de pages
A un web de Ressources
Mash-up
L’approche
Style d'architecture
Architecture
Technologies
REST
HTTP URIXML
Ab
straction
Ab
straction
( Web 2.0)ROA
Technologies
Crée une application RESTful
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
2 Permettre plusieurs représentations
GET http://dng.org/symposium/2008/sessions/day1Accept : text/html
Représentation
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
<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
<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
4 Utiliser l'interface uniforme d'HTTP
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
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
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
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
Approche services RPC
Calculatrice 4 opérations
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
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
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
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>
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
Architecture Orientée Ressource
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
Affichage
Construction des écrans
Traitementsmétiers
Données persistantes
Données de sessions
Mainframe / Client passif
Page 29
Interface ODBC/JDBC/...
Poste clientBase de données
Client-serveur / Client lourd
Page 30
Interface HTTP
NavigateurBase de donnéesServeur d'applications
Interface ODBC/JDBC/...
3 tiers / Client léger
Page 31
Interface de services
Ressources
Client richeServeur d'applications
ROA / Client riche
Base de données
Interface ODBC/JDBC/...
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
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
REST
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
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
Envoyer un message sur le réseau
Page 38
Principes d'architecture généraux
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
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
Le débat: SOAP vs REST
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
Technologies SOAP WSDL UDDI WS-*
HTTP URIXML
Les arguments des partisans d’HTTP seul
HTTP vs SOAP
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
WS-* est trop complexeCe sont les « big vendors » qui ont inventé et poussent SOAP / WS-*
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
Technologies SOAP WSDL UDDI WS-*
HTTP URIXML
Les arguments des partisans de SOAP
HTTP vs SOAP
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
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
Styled'architecture
Architecture ROA
RESTSOA
REST-ROA / SOA
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
RessourcesRessources ServicesServices
Ressources et Services
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
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
Traitements
Données
Backend
Frontend
Ressources et Services
ServicesSOA SOAP/WS-*
ServicesSOA SOAP/WS-*
RessourcesREST HTTP
RessourcesREST HTTP
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
“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
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
Restafarians ?
Page 60
La bible
Page 61
Le nouveau testament
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
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
- IstockPhoto pour les photos
- Le projet Crystal pour les icônes
- Mes collègues d'Atos Origin pour leurs retours critiques
Remerciements
Page 65
Annexes
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