Web des services : REST§

author:Pierre-Antoine Champin
date:2011-2015
license: Creative Commons License
1

L'intervenant

Ce support de cours est disponible à http://champin.net/enseignement/rest/.

2

Introduction§

3

Service Web§

Définition :

HTML y est donc remplacé par des formats de données, notamment XML ou JSON.

Cf. http://programmableweb.com/

4

Applications clientes§

5

REST§

6

REST par l'exemple§

7

Richardson Maturity Model§

Largement tiré du billet de blog de Martin Fowler.

_images/steps-towards-rest.png
8

Richardson Maturity Model§

On prend comme exemple un service de prise de rendez-vous avec des médecins.

On suppose que vous êtes en charge de développer:

L'API de votre service sera rendue publique, pour permettre le développement indépendant d'autres clients (applications mobiles, plugins pour des applications d'agenda, etc.).

9

Niveau 0 : POX (Plain Old XML)§

_images/interaction-level0.png
10

POX - Échange 1§

POST /appointmentService HTTP/1.1
[various headers]

<openSlotRequest date="2010-01-04" doctor="mjones"/>

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot doctor="mjones" start="1400" end="1450" />
  <slot doctor="mjones" start="1600" end="1650" />
</openSlotList>

Note

Le choix de XML n'est pas déterminant ici ; on aurait pu choisir un autre format (JSON, YAML...).

11

POX - Échange 2§

POST /appointmentService HTTP/1.1
[various headers]

<appointmentRequest>
  <slot doctor="mjones" start="1400" end="1450"/>
  <patient id="jsmith"/>
</appointmentRequest>

HTTP/1.1 200 OK
[various headers]

<appointment>
  <slot doctor="mjones" start="1400" end="1450"/>
  <patient id="jsmith"/>
</appointment>
12

POX - Échange 2 (échec)§

HTTP/1.1 200 OK
[various headers]

<appointmentRequestFailure>
  <slot doctor="mjones" start="1400" end="1450"/>
  <patient id="jsmith"/>
  <reason>Slot not available</reason>
</appointmentRequestFailure>
13

Niveau 1 : Ressources§

_images/interaction-level1.png

Principe : exposer au client les ressources qui constituent le service (via différentes URLs).

14

Ressources - Échange 1§

POST /appSvc/doctors/mjones HTTP/1.1
[various headers]

<openSlotRequest date="2010-01-04"/>

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot id="1234" doctor="mjones" start="1400" end="1450"/>
  <slot id="5678" doctor="mjones" start="1600" end="1650"/>
</openSlotList>

Note

Le contenu des messages est simplifié, car la ressource donne un contexte (ici : doctor="mjones")

15

Ressources - Échange 2§

POST /appSvc/slots/1234 HTTP/1.1
[various headers]

<appointmentRequest>
  <patient id="jsmith"/>
</appointmentRequest>

HTTP/1.1 200 OK
[various headers]

<appointment>
  <slot id="1234" doctor="mjones" start="1400" end="1450"/>
  <patient id="jsmith"/>
</appointment>
16

Ressources - Remarques§

17

Level 2 : Verbes et codes de status HTTP§

_images/interaction-level2.png

Principe : expliciter la sémantique de l'API via la sémantique de HTTP

18

HTTP - Échange 1§

GET /appSvc/doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot id="1234" doctor="mjones" start="1400" end="1450"/>
  <slot id="5678" doctor="mjones" start="1600" end="1650"/>
</openSlotList>
19

HTTP - Échange 2§

POST /appSvc/slots/1234 HTTP/1.1
[various headers]

<appointmentRequest>
  <patient id="jsmith"/>
</appointmentRequest>

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various other headers]

<appointment>
  <slot id="1234" doctor="mjones" start="1400" end="1450"/>
  <patient id="jsmith"/>
</appointment>
20

HTTP - Échange 2 (échec)§

HTTP/1.1 409 Conflict
[various headers]

<openSlotList>
  <slot id="5678" doctor="mjones" start="1600" end="1650"/>
</openSlotList>

Note

Un exemple d'utilisation de la sémantique des code de status HTTP est le comportement des navigateurs lorsqu'ils reçoivent un code 401 (Unauthorized) : au lieu de reporter l'erreur directement, ils réclament à l'utilisateur un login et un mot de passe.

21

HTTP - Avantage§

digraph intermédiaires { margin=0; rankdir=LR; client -> intermédiaire -> intermédiaire2 -> serveur intermédiaire2 [ label="..."; shape=none ] }

22

Level 3 : Hypermédia§

_images/interaction-level3.png

Principe : permettre au client de découvrir les actions possibles, plutôt que d'avoir à les connaître à l'avance.

23

Hypermédia - Échange 1§

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot id="1234" doctor="mjones" start="1400" end="1450">
     <book href="/appSvc/slots/1234"/>
  </slot>
  <slot id="5678" doctor="mjones" start="1600" end="1650">
     <book href="/appSvc/slots/5678"/>
  </slot>
</openSlotList>
24

Hypermédia - Échange 2 (succès)§

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]

<appointment uri="/slots/1234/appointment">
  <slot id="1234" doctor="mjones" start="1400" end="1450"/>
  <patient id="jsmith"/>
  <cancel href="/appSvc/slots/1234/appointment"/>
  <addTest href="/appSvc/slots/1234/appointment/tests"/>
  <changeTime
    href="/appSvc/doctors/mjones/slots?date=20100104&status=open"/>
  <updateContactInfo href="/patients/jsmith/contactInfo"/>
  <help href="http://appSvc.com/help/appointment"/>
</appointment>
25

Hypermédia - Avantages§

26

REST : le style architectural du Web§

27

Style architectural§

28

Objectifs§

« REST emphasizes

  • scalability of component interactions,
  • generality of interfaces,
  • independent deployment of components, and
  • intermediary components to
    • reduce interaction latency,
    • enforce security, and
    • encapsulate legacy systems. »

(Roy Fielding)

29

Passage à l'échelle§

Problème de performance

La dimension et l'expansion constante du Web obligent à considérer dès le départ les problèmes d'échelle.

Problème de robustesse

Le système ne peut pas être 100% opérationnel 100% du temps.

30

Généralité des interfaces§

Facilite le développement des composants

Réutilisation de bibliothèques standard, interopérabilité.

Évolutivité

Web de documents, Web de services, Web 2.0, Web des données, Web sémantique...

Principle of partial understanding (Michael Hausenblas)

31

Déploiement indépendant des composants§

Contrainte d'échelle

Pas de centralisation possible sur le Web.

Adoption et évolution rapides

Grassroot movement (poussé par le bas), « sélection naturelle », modèle du Bazar (Eric Raymond)

32

Composants intermédiaires§

Réduire la latence

Assurer la sécurité

Encapsulant des services

33

Contraintes§

Contraintes de REST, d'après Fielding :

NB: la description qui en suit doit beaucoup à Miguel Grinberg.

34

Client-serveur§

35

Client-serveur (2)§

Separation of concern (Edsger W. Dikstra)

Remarques :

36

Client-serveur (3)§

Note

Fournit "gratuitement" la possibilité d'avoir plusieurs clients.

37

Système en couches§

38

Système en couches (2)§

39

Système en couches (3)§

40

Support des caches§

41

Support des caches§

Note

Les verbes et les statuts pré-définis par HTTP ont une sémantique suffisamment précise pour informer les caches de la possibilité de « cacher » ou non un résultat.

NB: l'utilisation systématique de POST empêche l'exploitation des caches.

HTTP permet de contrôler plus finement le cache avec un certain nombres de champs d'en-tête (Cache-Control, Expires).

42

Connexion sans état§

Le serveur ne doit pas s'encombrer du contexte de l'interaction. Ce contexte est rappelé à chaque requête par le client, et les modifications de contexte sont indiquées dans la réponse.

→ auto-suffisance des messages.

Inconvénients

Avantages

43
Remarques§

Note

La plupart des framework de développement Web offrent des fonctionalités qui gèrent les sessions de manière quasiment transparente pour le développeur. Attention cependant à avoir conscience des avantages et des inconvénients.

44

Interface uniforme (1) : ressources§

45

Interface uniforme (2) : représentation§

Une ressource n'est manipulée par le client qu'à travers des représentations de son état.

_images/MagrittePipe.jpg

Tableau de René Magritte - Source Wikipedia
_images/ombre-chinoise.gif

La représentation n'est pas nécessairement exhaustive.
46

Interface uniforme (3) : messages auto-suffisants§

47

Interface uniforme (4) : hypermédia§

  • Hypertext As The Engine Of Application State (HATEOAS)
  • Notion d'affordance
_images/TheBigButton.jpg

Gary Larson
48

Interface uniforme (4) : hypermédia§

    http://www.google.fr/search?q=hypertexte

49
Motivation sous-jacente§

Le web des services n'est pas différent du web des documents : un agent (par exemple le navigateur) interagit avec des serveurs pour le compte d'un utilisateur.

La différence réside dans le degré d'autonomie de cet agent : différence de degré mais pas de nature.

50

Code à la demande (optionel)§

51

Discussions§

52

Représentation / Opérations§

Sémantique déclarative plutôt qu'opérationnelle

53

Analogie : les fichiers sous UNIX§

Une des évolutions majeures apportée par UNIX au domaine des systèmes d'exploitations a été l'unification de la notion de fichier :

pour manipuler des ressources aussi variées que des fichiers de données, des périphériques, des sockets...

→ le succès de cette unification donne un certain crédit à l'unification proposée par REST.

54

Cookies§

55

Cookies§

56

Description des interfaces : le chaînon manquant§

Contrairement à SOAP, REST ne dispose pas d'un langage standard pour la description formelle des interfaces des services.

Un tel langage offrirait pourtant des fonctionalités intéressantes :

57

Description des interfaces : le chaînon manquant§

Il y a eu de nombreuses propositions dans ce sens :

Mais aucune ne s'est encore imposée...

58

Autres lectures§

59

Annexes§

60

REST : une alternative à SOAP§

SOAP : Simple Object Access Protocol

Pourtant, SOAP recontre une certaine résistance

61

SOAP: Pas si « simple »...§

Une spécification volumineuse

SOAP est parfois perçu comme limitant paradoxalement l'interopérabilité des services Web.

62

SOAP: Pas si « Web »...§

Le succès du Web doit beaucoup à sa simplicité de mise en œuvre, simplicité qui fait défaut à SOAP.

Avec SOAP, le prototole HTTP est utilisé comme un simple protocole de transport.

→ SOAP se prive d'une grande partie des mécanismes du Web

63

Anatomie d'une requête HTTP§

L'« implémentation de référence » de REST.

64

Avertissement§

REST → HTTP mais

HTTP → REST

65

Exemple de requête HTTP§

Requête à http://www.w3.org/

GET / HTTP/1.1
Host: www.w3.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686;
       fr; rv:1.9.1) Gecko/20090624 Firefox/3.5
Accept: text/html,application/xhtml+xml,
       application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Connection: keep-alive
Keep-Alive: 300
66

Exemple de réponse HTTP§

Réponse de http://www.w3.org/

HTTP/1.x 200 OK
Date: Mon, 02 Nov 2009 22:46:26 GMT
Server: Apache/2
Accept-Ranges: bytes
Content-Type: text/html; charset=utf-8
Content-Length: 29794
Etag: "7462-477341dcfb940;89-3f26bd17a2f00"
Last-Modified: Sat, 31 Oct 2009 05:07:09 GMT
Content-Location: Home.html
Vary: negotiate,accept
Cache-Control: max-age=600
Expires: Mon, 02 Nov 2009 22:56:26 GMT
Connection: close

(data)                                                        ...
67

Sémantique de la requête et de la réponse§

La requête consiste à appliquer un verbe à la ressource.

GET / HTTP/1.1
Host: www.w3.org

La réponse commence par un code de statut numérique indiquant le résultat .

HTTP/1.x 200 OK
68

Verbes§

HTTP définit quatre (principaux) verbes pour la manipulation des ressources :

Les requêtes POST et PUT supposent un envoi de données (payload) au serveur. Ces données peuvent être de n'importe quel type, qui sera spécifié dans la requête (Content-Type).

69
Verbes (suite)§

Certains auteurs préfèrent caractériser les verbes HTTP simplement par rapport à leurs propriétés :

qui conditionnent le comportement des composants intermédiaires.

70

Codes de statut§

HTTP définit 40 codes de statut, répartis en cinq catérogires :

Catégories Exemples
1xx : Information 100 Continue
2xx : Succès 200 OK
3xx : Redirection 301 Moved Permanently
4xx : Erreur client 404 Not Found, 401 Unauthorized
5xx : Erreur serveur 500 Internal Server Error
71

Identification§

Le client et le serveur donnent des indications sur leur identité et leur contexte.

User-Agent: Mozilla/5.0 (X11; U; Linux i686;
       fr; rv:1.9.1) Gecko/20090624 Firefox/3.5

Server: Apache/2
Date: Mon, 02 Nov 2009 22:46:26 GMT
72

Négociation de contenu (1)§

Le client annonce les types de contenus qu'il est capable d'accepter.

Accept: text/html,application/xhtml+xml,
        application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*

Content-Type: text/html; charset=utf-8
Content-Location: Home.html
Vary: negotiate,accept
73

Négociation de contenu (2)§

En-tête Alternates de http://www.w3.org/

Alternates: {"Home.html" 1 {type text/html} {charset utf-8} {length 29813}},
{"Home.xhtml" 0.99 {type application/xhtml+xml} {charset utf-8} {length 29813}}
74

Méta-données de cache (1)§

Le serveur fournit des méta-données relatives à la représentation.

Etag: "7462-477341dcfb940;89-3f26bd17a2f00"
Last-Modified: Sat, 31 Oct 2009 05:07:09 GMT

Ces méta-données font partie de l'état du client, et sont donc censées être fournie par lui lors de requêtes ultérieures (statelessness).

If-None-Match: "7462-477341dcfb940;89-3f26bd17a2f00"
If-Modified-Since: Sat, 31 Oct 2009 05:07:09 GMT

Si la ressource n'a pas été modifiée, le serveur répondra par un statut 304 Not Modified et une réponse vide → économie.

75

Méta-données de cache (2)§

D'autres méta-données concernent la « cachabilité » de la représentation.

Cache-Control: max-age=600
Expires: Mon, 02 Nov 2009 22:56:26 GMT

Cache-Control (introduit dans HTTP 1.1) offre plus d'expressivité que Expires (private, no-transform...).

Cache-Control peut également être utilisé dans une requête, par exemple :

Cache-Control: no-cache
76

Méta-données de connexion§

HTTP étant un protocole sans état, chaque requête peut être envoyée sur une nouvelle connexion TCP (ce qui était imposé par HTTP 1.0).

Pour des raisons d'optimisation, le client et le serveur peuvent spécifier qu'ils souhaitent / acceptent de garder la connexion ouverte pour des requêtes ultérieures. Ceci est fait explicitement pour conserver l'auto-suffisance des requêtes.

Connection: keep-alive
Keep-Alive: 300

Connection: close
77