.. Web des services : REST slides file, created by hieroglyph-quickstart on Fri Nov 1 12:34:44 2013. :tocdepth: 3 .. rst-class:: sab-printable ========================= Web des services : REST ========================= :author: `Pierre-Antoine Champin`_ :date: 2011-2015 :license: |cc| .. _Pierre-Antoine Champin: http://champin.net/#pa .. slide:: L'intervenant :level: 3 * Pierre-Antoine Champin * enseignant-chercheur au LIRIS_ `Lyon 1`_ * http://champin.net/ Ce support de cours est disponible à http://champin.net/enseignement/rest/. .. _LIRIS: http://liris.cnrs.fr/ .. _Lyon 1: http://www.univ-lyon1.fr/ Introduction ============ Service Web +++++++++++ Définition : * Application Web, coté serveur, * destinée à être utilisée par des programmes, * et non par des utilisateurs (à travers un navigateur). HTML y est donc remplacé par des formats de données, notamment XML ou JSON. Cf. http://programmableweb.com/ Applications clientes +++++++++++++++++++++ * applications de bureau * applications mobiles * autres services Web .. rst-class:: build * code Javascript s'exécutant sur le navigateur → la distinction entre "site Web" et "service Web" s'estompe REST ++++ .. rst-class:: build * *Representational State Transfer* * Un style architectural * Un ensemble de bonne pratiques pour la conception de service Web * Une religion (RESTful, RESTlike, RESTafarians...) REST par l'exemple ================== Richardson Maturity Model +++++++++++++++++++++++++ Largement tiré du `billet de blog de Martin Fowler`__. __ http://martinfowler.com/articles/richardsonMaturityModel.html .. figure:: _static/steps-towards-rest.png .. nextslide:: 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: * le service lui même (coté serveur), et * un client AJAX. 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.). Niveau 0 : POX (Plain Old XML) ++++++++++++++++++++++++++++++ .. figure:: _static/interaction-level0.png :width: 100% POX - Échange 1 --------------- .. code-block:: xml POST /appointmentService HTTP/1.1 [various headers] .. code-block:: xml HTTP/1.1 200 OK [various headers] .. note:: Le choix de XML n'est pas déterminant ici ; on aurait pu choisir un autre format (JSON_, YAML_...). .. _JSON: http://json.org/ .. _YAML: http://yaml.org/ POX - Échange 2 --------------- .. code-block:: xml POST /appointmentService HTTP/1.1 [various headers] .. code-block:: xml HTTP/1.1 200 OK [various headers] POX - Échange 2 (échec) ----------------------- .. code-block:: xml HTTP/1.1 200 OK [various headers] Slot not available Niveau 1 : Ressources +++++++++++++++++++++ .. figure:: _static/interaction-level1.png :width: 100% Principe : exposer au client les **ressources** qui constituent le service (*via* différentes URLs). Ressources - Échange 1 ---------------------- .. code-block:: xml POST /appSvc/doctors/mjones HTTP/1.1 [various headers] .. code-block:: xml HTTP/1.1 200 OK [various headers] .. note:: Le contenu des messages est simplifié, car la ressource donne un contexte (ici : ``doctor="mjones"``) Ressources - Échange 2 ---------------------- .. code-block:: xml POST /appSvc/slots/1234 HTTP/1.1 [various headers] .. code-block:: xml HTTP/1.1 200 OK [various headers] Ressources - Remarques ---------------------- * En théorie, les différentes URLs peuvent être construites de n'importe quelle manière. Par exemple : .. list-table:: + - ``appSvc/doctor/mjones`` - ``appSvc/slot/1234`` + - ``appSvc?doctor=mjones`` - ``appSvc?slot=1234`` + - ``appSvc/7c277937e450`` - ``appSvc/d75bdf681d78`` + - ... - ... * En pratique, + les URLs lisibles sont plus appropriables par les utilisateurs et les dévelopeurs, + les URLs de type "chemin" ("/") permettent d'utiliser des URLs *relatives*. Level 2 : Verbes et codes de status HTTP ++++++++++++++++++++++++++++++++++++++++ .. figure:: _static/interaction-level2.png :width: 100% Principe : expliciter la sémantique de l'API *via* la sémantique de HTTP HTTP - Échange 1 ---------------- .. code-block:: xml GET /appSvc/doctors/mjones/slots?date=20100104&status=open HTTP/1.1 Host: royalhope.nhs.uk .. code-block:: xml HTTP/1.1 200 OK [various headers] HTTP - Échange 2 ---------------- .. code-block:: xml POST /appSvc/slots/1234 HTTP/1.1 [various headers] .. code-block:: xml HTTP/1.1 201 Created Location: http://royalhope.nhs.uk/slots/1234/appointment [various other headers] HTTP - Échange 2 (échec) ------------------------ .. code-block:: xml HTTP/1.1 409 Conflict [various headers] .. 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. HTTP - Avantage --------------- * Profite aux **intermédiaires** + bibliothèque HTTP coté client + serveur d'application coté serveur + proxy, firewall .. digraph:: intermédiaires margin=0; rankdir=LR; client -> intermédiaire -> intermédiaire2 -> serveur intermédiaire2 [ label="..."; shape=none ] * Optimisation (gestion d'erreur, cache), **selon la sémantique** du verbe : + GET : idempotent, sans effet de bord + PUT, DELETE : idempotent, avec effet de bord + POST : non-idempotent, avec effet de bord Level 3 : Hypermédia ++++++++++++++++++++ .. figure:: _static/interaction-level3.png :width: 100% Principe : permettre au client de **découvrir** les actions possibles, plutôt que d'avoir à les connaître à l'avance. Hypermédia - Échange 1 ---------------------- .. code-block:: xml GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1 Host: royalhope.nhs.uk .. code-block:: xml HTTP/1.1 200 OK [various headers] Hypermédia - Échange 2 (succès) ------------------------------- .. code-block:: xml HTTP/1.1 201 Created Location: http://royalhope.nhs.uk/slots/1234/appointment [various headers] Hypermédia - Avantages ---------------------- * Réduit le **couplage** entre client et serveur, en diminuant les connaissances *a priori* nécessaires coté client : + le client doit toujours "connaitre" le format XML, + mais plus la manière de construire les URLs. * Le serveur peut, sans "casser" les clients : + changer la structure de ses URLs, + déléguer certaines ressources à d'autres serveurs, + créer de nouvelles fonctionalités (en enrichissant le XML). REST : le style architectural du Web ==================================== Style architectural +++++++++++++++++++ * Notion proposée par Roy Fielding dans `sa thèse `_ (2000) : `Architectural Styles and the Design of Network-based Software Architectures`. * Défini comme un ensemble de **contraintes** imposées sur la conception d'un système pour garantir un certain nombre de **propriétés**. * La question sous-jacente était d'identifier les contraintes à respecter dans le développement du Web : * pour conserver les propriétés ayant fait son succès, * pour corriger les problèmes constatés, * pour évaluer les évolutions futures des technologies. 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) Passage à l'échelle ------------------- .. rubric:: 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. .. rubric:: Problème de robustesse Le système ne peut pas être 100% opérationnel 100% du temps. Généralité des interfaces ------------------------- .. rubric:: Facilite le développement des composants Réutilisation de bibliothèques standard, interopérabilité. .. rubric:: Évolutivité Web de documents, Web de services, Web 2.0, Web des données, Web sémantique... *Principle of partial understanding* (Michael Hausenblas) Déploiement indépendant des composants -------------------------------------- .. rubric:: Contrainte d'échelle Pas de centralisation possible sur le Web. .. rubric:: Adoption et évolution rapides *Grassroot movement* (poussé par le bas), « sélection naturelle », modèle du Bazar (Eric Raymond) * e.g. : Mosaic → Netscape, CERN httpd → Apache .. _composants_intermediaires: Composants intermédiaires ------------------------- .. rubric:: Réduire la latence * en conservant en cache le résultat de certaines requêtes (*proxy*), * en répartissant la charge entre plusieurs serveurs redondants (*reverse proxy*). .. rubric:: Assurer la sécurité * en masquant l'accès à certains serveurs (*proxy* filtrant, *reverse proxy*, n-tiers). .. rubric:: Encapsulant des services * en adaptant les requêtes (*gateway*) ← généralité des interfaces Contraintes +++++++++++ Contraintes de REST, d'après Fielding : * client-serveur * connexion sans état (*stateless*) * support des caches * interface uniforme * système en couches * code à la demande (optionel) NB: la description qui en suit doit beaucoup à `Miguel Grinberg`__. __ https://www.youtube.com/watch?v=pZYRC8IbCwk .. _client-server: Client-serveur -------------- .. figure:: _static/clientserver1.svg .. nextslide:: :increment: *Separation of concern* (Edsger W. Dikstra) * Le serveur est responsable du stockage et de la cohérence des données (*état des ressources*). * Le client est responsable : * de la présentation/du traitement des données, * de maintenir le contexte/état de l'*interaction* (cf. ci après). .. rst-class:: build Remarques : * Cette séparation peut être appliquée, même si le client et le serveur sont sur le même machine. * Certains composants sont à la fois client et serveur (e.g. proxy). Ils respectent cependant la séparation des préoccupations *vis-à-vis* des composants avec lesquels ils communiquent. .. nextslide:: :increment: .. figure:: _static/clientserver2.svg .. note:: Fournit "gratuitement" la possibilité d'avoir plusieurs clients. .. _layered-system: Système en couches ------------------ .. figure:: _static/layered1.svg .. nextslide:: :increment: * Cette contrainte spécifie qu'un composant ne doit se soucier que de ses interlocuteurs directs. * Le protocole HTTP assure lui même la cohérence des messages le long de la chaîne d'intérmédiaires en spécificiant, en fonction de leur sémantique, quelles parties d'une requête ou d'une réponse sont *Hop-by-hop* ou *End-by-end*. * Permet la mise en place de `composants_intermediaires`:ref:. .. nextslide:: :increment: .. figure:: _static/layered2.svg .. _cache-support: Support des caches ------------------ .. figure:: _static/cache1.svg .. nextslide:: .. figure:: _static/cache2.svg .. 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``). .. _stateless: 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 * surcoût en bande passante * authentification à chaque requête (→ HTTPS) Avantages * performances (un serveur / beaucoup de clients) * robustesse (redémarrage ou changement de serveur, **clients nomades**) * facilite le travail des intermédiaires Remarques ````````` * On parle bien ici de l'état du *client*. Le serveur gère évidemment l'état des *ressources* dont il a la charge. * Cette contrainte est souvent violée par les sites web (identifiants de session, cookies), censément pour améliorer - l'expérience utilisateur, - la sécurité (expiration des sessions). * Les sessions empèchent cependant + de bénéficier des caches, + de mettre un signet sur certaines pages, + de travailler en parallèle dans plusieurs onglets... .. 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. Interface uniforme (1) : ressources ----------------------------------- * Une ressource est un constituant du service (médecin, créneau horaire, rendez-vous, patient). + Une collection de ressource est aussi une ressource. * Toute ressource est identifiée par une **URL**. + Réciproquement, deux URLs différentes identifient (*a priori*) des ressources différentes. * Une ressource a un **état** interne (données stockées sur le serveur) + qui varie dans le temps, + et qui est inaccessible aux clients. Interface uniforme (2) : représentation --------------------------------------- Une ressource n'est manipulée par le client qu'à travers des **représentations** de son état. .. list-table:: * - .. figure:: _static/MagrittePipe.jpg :width: 100% Tableau de René Magritte - Source Wikipedia__ - .. figure:: _static/ombre-chinoise.gif :width: 100% La représentation n'est pas nécessairement *exhaustive*. __ https://en.wikipedia.org/wiki/File:MagrittePipe.jpg Interface uniforme (3) : messages auto-suffisants ------------------------------------------------- * La sémantique de la requête est entièrement portée par le message : + verbe (GET, PUT, POST, DELETE) + URL cible + en-têtes éventuels + représentation éventuelle * Très lié à `layered-system`:ref: et `stateless`:ref:. Interface uniforme (4) : hypermédia ----------------------------------- .. list-table:: * - + *Hypertext As The Engine Of Application State* (HATEOAS) + Notion d'**affordance** - .. figure:: _static/TheBigButton.jpg :width: 100% Gary Larson .. nextslide:: * La représentation d'une ressource comporte les **liens** vers d'autres ressources (identifiées par leurs URIs). * La sémantique du lien dépend du *format* de la représentation. * L'état d'un client change en *suivant* les liens découvert dans les représentations. * NB : Une alternative consiste à *construire* un URI en fonction des informations fournies par une représentation. C'est le cas des formulaires HTML utilisant la méthode GET, e.g.: ``    http://www.google.fr/search?q=hypertexte`` 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*. Code à la demande (optionel) ---------------------------- * Cette contrainte consiste à permettre au serveur d'envoyer au client non seulement la description d'un état, mais également une logique de traitement (programme). * On peut voir AJAX (*Asynchronous Javascript and XML*) et ses dérivés (JSON) comme une généralisation de ce principe (même si AJAX n'utilise pas forcément des échanges RESTful). Discussions =========== Représentation / Opérations +++++++++++++++++++++++++++ Sémantique déclarative plutôt qu'opérationnelle * Alors que d'autres approaches (OOP, SOAP) mettent l'accent sur les *opérations*, REST fournit un ensemble pré-défini d'opétations (interface unifiée) et met l'accent sur les *représentations*. * La logique métier est donc principalement portée par le *format* des données échangées. 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 : * un espace de nommage unique (le système de fichier) * une interface uniforme (``open``, ``read``, ``write``...) 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. Cookies +++++++ * Un cookie est une chaîne de caractères associée au site, envoyée par le serveur, et que le client doit joindre à toute future requête sur ce serveur. * Le plus souvent, cette chaîne est un jeton opaque interprétable uniquement par le serveur (analogie aux *fortune cookies*). .. nextslide:: * respectent le principe d'auto-suffisance des requêtes + et préférable à un identifiant de session passé dans l'URL! * violent le principe de `stateless`:ref: + sauf mettre dans le cookie une description explicite, plutôt qu'un jeton opaque * changent *a posteriori* la sémantique des requêtes précédemment effectuées + « cassent » le bouton *back* et certains mécanismes de cache 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 : * vérification automatique de la conformité, * génération automatique de code (squelettes, *stubs*), * configuration automatique. .. nextslide:: Il y a eu de nombreuses propositions dans ce sens : * `WSDL 2.0 `_ (2003) * `hRESTS `_ et `SA-REST `_ (2007-2008) * `WADL `_ (2009) * `HYDRA `_ (2012) Mais aucune ne s'est encore imposée... Autres lectures =============== * http://blog.octo.com/designer-une-api-rest/ Annexes ======= REST : une alternative à SOAP +++++++++++++++++++++++++++++ SOAP : *Simple Object Access Protocol* * Une recommandation du W3C (2003) pour l'échange de données entre services Web (cf. séance précédente). * Poussée par des membres influents du consortium (Microsoft, Sun, IBM, Canon, Oracle). Pourtant, SOAP recontre une certaine résistance * REST (*Representational State Transfer*), notion proposée en 2000 par Roy Fielding, est proposé comme une alternative. * En 2006, `Google abandonne son API SOAP`__ au profit d'une API simplifiée REST-like. __ http://radar.oreilly.com/archives/2006/12/google-depreciates-SOAP-API.html SOAP: Pas si « simple »... -------------------------- Une spécification volumineuse * Son ampleur décourage certains implémenteurs : pas d'implémentation complète dans certains langages (PHP, Python...). * Ce phénomène est amplifié par une profusion d'*extensions* (WS-Policy, WS-Security, WS-Trust, etc.)... * ... et le fait que leurs implémentations ne sont pas toujours homogènes. SOAP est parfois perçu comme *limitant* paradoxalement l'interopérabilité des services Web. SOAP: Pas si « Web »... ----------------------- Le succès du Web doit beaucoup à sa *simplicité* de mise en œuvre, simplicité qui fait défaut à SOAP. * cf. transparent précédent Avec SOAP, le prototole HTTP est utilisé comme un simple protocole de transport. * C'est un choix délibéré (indépendance des couches, modèle OSI). * Pourtant, HTTP a été conçu comme un protocole *applicatif*. → SOAP se prive d'une grande partie des mécanismes du Web Anatomie d'une requête HTTP +++++++++++++++++++++++++++ L'« implémentation de référence » de REST. Avertissement ------------- REST → HTTP mais * HTTP est largement implémenté. * Tout protocole RESTful serait amené à réinventer une grande partie de HTTP. + "any sufficiently sophisticated program implements a buggy subset of half a Common Lisp interpreter" HTTP → REST * HTTP 1.1 comporte des compromis (compatibilité avec l'existant) * Il existe plusieurs manières d'utiliser HTTP, et toutes ne sont pas RESTful (e.g. SOAP). * Certaines extensions de HTTP sont « RESTless » (e.g. cookies). Exemple de requête HTTP ----------------------- .. rubric:: Requête à http://www.w3.org/ .. rst-class:: request .. code-block:: http 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 Exemple de réponse HTTP ----------------------- .. rubric:: Réponse de http://www.w3.org/ .. rst-class:: response .. code-block:: http 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) ... Sémantique de la requête et de la réponse ----------------------------------------- La requête consiste à appliquer un *verbe* à la ressource. * GET signifie ici « obtenir une représentation de la ressource ». * Le champs ``Host`` est obligatoire depuis HTTP/1.1 (car un même serveur peut servir plusieurs noms de domaine). .. rst-class:: request .. code-block:: http GET / HTTP/1.1 Host: www.w3.org La réponse commence par un *code de statut* numérique indiquant le résultat . * Le code est suivi d'un libellé textuel pour améliorer la lisibilité. .. rst-class:: response .. code-block:: http HTTP/1.x 200 OK Verbes ------ HTTP définit quatre (principaux) verbes pour la manipulation des ressources : * GET : récupérer l'état de la ressource * PUT : attribuer l'état de la ressource * DELETE : supprimer la ressource * POST : fournir des données à la ressource 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``). Verbes (suite) `````````````` Certains auteurs préfèrent caractériser les verbes HTTP simplement par rapport à leurs propriétés : * GET : idempotente, sans effet de bord * PUT, DELETE : idempotente, avec effet de bord * POST : non-idempotente, avec effet de bord qui conditionnent le comportement des composants intermédiaires. Codes de statut --------------- HTTP définit 40 codes de statut, répartis en cinq catérogires : .. list-table:: :header-rows: 1 * - 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 Identification -------------- Le client et le serveur donnent des indications sur leur identité et leur contexte. * Utile notamment pour les terminaux mobiles. .. rst-class:: request .. code-block:: http User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1) Gecko/20090624 Firefox/3.5 .. rst-class:: response .. code-block:: http Server: Apache/2 Date: Mon, 02 Nov 2009 22:46:26 GMT Négociation de contenu (1) -------------------------- Le client annonce les types de contenus qu'il est capable d'accepter. .. rst-class:: request .. code-block:: http 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,* .. rst-class:: response .. code-block:: http Content-Type: text/html; charset=utf-8 Content-Location: Home.html Vary: negotiate,accept Négociation de contenu (2) -------------------------- * Si aucune représentation disponible ne peut satisfaire le client, le serveur peut retourner une code 406 *Not Acceptable*. * Il doit normalement fournir dans la réponse une liste des représensentations disponibles. * L'agent (logiciel client) est autorisé à sélectionner automatiquement l'une de ces représentations. * Cette information peut également être fournie dans l'entête de la réponse (non standard). .. rubric:: En-tête Alternates de http://www.w3.org/ .. rst-class:: response .. code-block:: http 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}} Méta-données de cache (1) ------------------------- Le serveur fournit des méta-données relatives à la représentation. .. rst-class:: response .. code-block:: http 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*). .. rst-class:: request .. code-block:: http 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. Méta-données de cache (2) ------------------------- D'autres méta-données concernent la « cachabilité » de la représentation. .. rst-class:: response .. code-block:: http 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 : * pour spécifier sa tolérance à la « vieillesse » de la réponse, * pour forcer un rechargement: .. rst-class:: request .. code-block:: http Cache-Control: no-cache 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. .. rst-class:: request .. code-block:: http Connection: keep-alive Keep-Alive: 300 .. rst-class:: response .. code-block:: http Connection: close .. ######## SUBSTITUTIONS ######## .. |cc| raw:: html Creative Commons License