The document discusses the evolution of the web as a hypertext system beginning with Tim Berners-Lee's introduction of the World Wide Web in 1991 and the subsequent establishment of standards by the W3C. It navigates the significance of REST (Representational State Transfer) in web architecture, contrasting it with earlier concepts of hypertext and detailing how REST principles were refined to accommodate modern web applications. Key themes include the interface between URLs and URNs, discussions on resource identification, and the adaptation of HTTP standards to meet architectural principles informed by REST.

1. LO10 – UTT
Cours sur REST
Alexandre Monnin (Origens Medialab)

2.  Le Web est-il un hypertexte?
F
Le réseau
comme
hypertexte

3. Bien sûr!
• protocole : “HyperText Transfer Protocol” (HTTP)
• langage : “HyperText Markup Language” (HTML)
F

4. Bien sûr !
Le « Web » fut presenté lors de la 3e conférence ACM
Hypertext en 1991 (San Antonio, Texas)
F

5. Bien sûr!
• A lire sur le site du CERN : “On 6 August 1991, Tim Berners-Lee
posted a summary of the World Wide Web project on several
internet newsgroups, including alt.hypertext, which was for
hypertext enthusiasts. The move marked the debut of the web
as a publicly available service on the internet”.
• Berners-Lee et Cailliau ont tous deux reconnu l’influence des
pionnier de l’hypertexte.
• En particulier Vannevar Bush et Ted Nelson – même si le
Memex de Bush n’était pas véritablement un hypertexte (cf.
Alexandre Serres, “Hypertexte”). Il faudrait également ajouter
Doug Engelbart.
F

6. Sauf que non…
Les fonctionnalités de Xanadu, caractéristiques des
hypertexts, ont disparu avec le Web :
• les liens bidirectionnels (pas de liens cassés!)
• la transclusion (Nelson: “A link connects two things which
are different. . A transclusion connects two things which
are the same”).
• la gestion du copyright, du micropaiement, et la sécurité
• le “version-management”
• le “content management”

7. REST et l’architecture du Web

8. a naming system (UDI/URI/URL /URN/URC/IRL/IRI)
http://wimmics.inria.fr
communication / protocol (HTTP)
GET /team HTTP/1.1
Host: wimmics.inria.fr
representation language (HTML, XML, JSON,…)
Fabien is a member of
<a href="http://wimmics.inria.fr">Wimmics</a>
Architecture du Web ?

9. a Web of amateurs?
Alan Kay a dit un jour : “the Internet was done so well that most people think of it
as a natural resource like the Pacific Ocean, rather than something that was man-
made. When was the last time a technology with a scale like that was so error-
free? The Web, in comparison, is a joke. The Web was done by amateurs.”
Un contributeur de Stack Overflow, Stephen Crawley, apporte la réponse suivante :
“In a sense he was right. The original (pre-spec) versions of HTML, HTTP and URL
were designed by amateurs (not standards people). And there are aspects of the
respective designs ... and the subsequent (original) specs ... that are (to put it
politely) not as good as they could have been. (…) However, the web has
succeeded magnificently despite these things. And all credit should go to the
people who made it happen. Whether or not they were "amateurs" at the time,
they are definitely not amateurs now.”

10. La naissance du W3C et la
standardization du Web
• 1994
• Partir des prototypes pour aller vers les standards
• Les premiers standards :
• Entre 1994 et 1995 : URLs, URNs, URCs and IRLs
• Février 1996 : HTTP 1.0
F

11. Des URI aux URI
21 AVRIL 2015 - 11
Uniform Resource Locators Uniform Resource Names
- Adresses de choses
accessibles. (« pages
Web »)
- Des choses qui changent
sans cesse.
- Noms d’objets dans le
monde ou de concepts
intangibles (inaccessibles)
- Des choses qui ne changent
pas (ex. : La recherche du
temps perdu).
http://www.inria.fr
http://ns.inria.fr/fabien.gan
don#me
ldap://[2001:db8::7]/c=GB?obj
ectClass?one

12. - 12
Uniform Resource Locators
a) Les URL ne donnent pas seulement accès à des
contenus « en ligne » mais permettent également de
donner accès à des descriptions de tous types d’objets
(ceci inclut les objets réputés « inaccessibles »).
b)Il n’est donc pas interdit de donner accès à des
descriptions de contenus jugés accessibles (la page
d’accueil du Monde par ex.).
 Aussi n’y a-t-il pas de différence, du point de vue des
URL, entre contenus accessibles et inaccessibles, et les
URL peuvent-elles désigner autant d’objets (voire les
mêmes) que les URN.
Uniform Resource Names
a) Les objets désignés par les URN sont considérés comme
immuables car les URN ont été conçues sur le modèles
des identifiants bibliothéconomiques, elles désignent des
réalités traitées de manières artificiellement stables dans
l’univers de la documentation (éditions, exemplaire,
articles, etc.)
b) Comment accéder à des informations à propos de ces
réalités ?
 Soit, chaque les gestionnaires de chaque schéma d’URN
élabore un protocole dédié.
 Soit on utilise le protocole Http, le protocole du Web et
alors il ne subsiste plus de différences avec les URL.

13. • Des controverses ont surgi concernant sur le fait de scinder les URI en URN et
URL.
• Cette opération reposait sur une distinction entre documents et choses
• Ce qui est « sur » le Web et ce qui est « en dehors » du Web
• Cette distinction, réactivée à l’époque du Web Sémantique, est largement
inconsistante
• Les standards furent révisés dès 1997 (HTTP 1.1) et 1998 (URI – un standard
fut dédié aux seules URL pendant à peine 3 ans).
« Web Resources »

14. Vers REST
• A partir de 19985 : Roy Fielding tente d’éclairer les grands principes du Web en
terme de design
• Principal éditeur de la recommendation sur HTTP 1.1 (1997) et les URI (1998)
• REST (pour REpresentational State Transfer : 1995 – 2000).
• REST a rendu explicites et les grands principes découverts déjà présents dans le
Web (vision réaliste)
• Il s’est aussi évertué d’implémenter ces principes dans le Web modernes (point
de vue constructiviste).
• Il a participé activement à la réécriture des standards du Web afin de les rendre compatibles
avec les principes mis à jour dans REST
• Ces principes avaient été abstraits et affinés à partir des premiers prototypes et standards,
standards qui furent à leur tour réécrits du fait de leur « Restfulness » insuffisante !

15. REST : un historique
• Pour un bref historique, voir la première section de Reflections on the
REST Architectural Style and “Principled Design of the Modern Web
Architecture” (Fielding et al. 2017).
• Voir aussi Alexandre Monnin, « Vers une Philosophie du Web Le Web
comme devenir-artefact de la philosophie (entre URIs, Tags,
Ontologie(s) et Ressources) ». Thèse de doctorat, Université Paris 1
Panthéon-Sorbonne, 2013.

16. “The first version of what eventually became “Principled Design of the
Modern Web Architecture” was submitted to FSE99. It was rejected,
with reviewer comments including “Over all, the originality of the
paper is quite low. There is only little to learn from it.” and “- the web is
old technolgoy [sic] now. - lots of jargon make the paper difficult to
understand. ... - I can’t find a novel lessons [sic] for software engineers
in this paper.”
(Fielding et al. 2017)

17. L’œuf ou la poule ?
t1) Http – Un modèle de REST ?
t2) REST – Principes extraits du modèle
t3) REST – Principes affinés, autonomisés, deviennent une norme
t4) Http – Devient une instance partielle de REST
 Fielding a oeuvre pour rendre le Web coherent avec lui-même.

18. “> Logically, REST really had to predate HTTP 1.1 in order for HTTP 1.1 to be so RESTful. No?
No. That is more of a philosophical question than a logical one. HTTP/1.1 is a specific
architecture that, to the extent I succeeded in applying REST-based design, allows people to
deploy RESTful network-based applications in a mostly efficient way, within the constraints
imposed by legacy implementations. The design principles certainly predated HTTP, most of
them were already applied to the HTTP/1.0 family, and I chose which constraints to apply
during the pre-proposal process of HTTP/1.1, yet HTTP/1.1 was finished long before I had the
available time to write down the entire model in a form that other people could understand.
All of my products are developed iteratively, so what you see as a chicken and egg problem is
more like a dinosaur-to-chicken evolution than anything so cut and dried as the conceptual
form pre-existing the form. HTTP as we know it today is just as dependent on the
conceptual notion of REST as the definition of REST is dependent on what I wanted HTTP to
be today.”

19. Roy T. Fielding/
Tim Berners-Lee
Credits Paul Downey

20. Saint Paul/
Jésus
(?)

22. REST = Transfert d’états représentationnels
▪la ressource
▪l’état de la ressource
▪l’état représentationnel
ou représentation de la ressource
- 22
« … »

23. “7.1.2 Manipulating Shadows. Defining resource such that a URI
identifies a concept rather than a document leaves us with another
question: how does a user access, manipulate, or transfer a concept
such that they can get something useful when a hypertext link is
selected? REST answers that question by defining the things that are
manipulated to be representations of the identified resource, rather
than the resource itself. An origin server maintains a mapping from
resource identifiers to the set of representations corresponding to
each resource. A resource is therefore manipulated by transferring
representations through the generic interface defined by the resource
identifier.”
(Roy T. Fielding & Richard Taylor, 2002)

24. Qu’est-ce qu’une URI nomme ou désigne?
• le Web n’a ni système de gestion des versions, ni système intégré d’archivage
(tout, sur le Web, disparaît par défaut) : il ne donne pas un identifiant à chaque
version d’une représentation (qu’il ne conserve pas !)
• les contenus changement au fil du temps (variations diachroniques)
• les contenus sont susceptibles de changer à chaque fois qu’une URI est sollicitée
(une URI peut identifier un service, gérer une représentation qui croise une
multitude d’appels à d’autres ressources, être le résultat de nombreux appels
générant un résultat comparables à un mashup, les « pages » contiennent des
compteurs, varient en fonction de la négociation de contenu ou de la
personnalisation, etc.) (variations synchroniques)
• les pointeurs peuvent cesser d’être déréférençables (« les liens se cassent »)
• n’importe quel objet peut être désigné (rompant avec la distinction en ligne/hors
ligne)

25. Un Web de
documents
?
Non ! Un Web de
Ressources !
« … »

26. Dé-spatialiser les URI
(adresses vs identifiants)

27. Quelques conséquences

29. "Resources are angels,
URIs pins" (Larry Masinter)

30. Web Sémantique : Principe AAA  Anyone can say anything about Anything
Web : Principe ADA  Anyone Can designate Anything (any Resource)

31. Hypertexte ?
http://roy.gbiv.com/untangled/2008
/rest-apis-must-be-hypertext-driven

32. Les principales propriétés du
style REST

33. “As an architectural style for network-based applications, its definition is
presented in the dissertation incrementally, as an accumulation of design
constraints that derive from nine pre-existing architectural styles and fi ve
additional constraints unique to the Web. Figure 1 shows the style derivation
graph for REST and highlights the associated constraints and induced
properties. Each style induces specific architectural properties, some positive
and some negative (a.k.a., trade-offs). Some of the styles are implied by the
Web’s requirements; others were chosen for their beneficial properties, or to
counteract the trade-off s of another style. The detailed discussion of this
derivation can be found on pages 76-86 of the dissertation.”
(Fielding et al. 2017)

34. Fielding et al. 2017.

35. Fielding et al. 2017.

36. Fielding et al. 2017.

37. REST (Erenkrantz et al. 2007)
RP1 The key abstraction of information is a resource, named by an URL.
RP2 The representation of a resource is a sequence of bytes, plus representation
metadata to describe those bytes.
RP3 All interactions are context-free.
RP4 Only a few primitive operations are available.
RP5 Idempotent operations and representation metadata are encouraged in
support of caching.
RP6 The presence of intermediaries is promoted.

38. REST
RP1 : The key abstraction of information is a resource, named by an URL.
• “Any information that can be named can be a resource: a document or
image, a temporal service (e.g., “today’s weather in Dubrovnik”), a
collection of other resources, a moniker for a nonvirtual object (e.g., a
person), and so on.”

39. REST
RP2 : The representation of a resource is a sequence of bytes, plus
representation metadata to describe those bytes.
• “Hence, REST introduces a layer of indirection between an abstract
resource and its concrete representation. Of particular note, the particular
form of the representation can be negotiated between REST components.”

40. REST
RP3 : All interactions are context-free.
• “This is not to imply that REST applications are without state, but that each
interaction contains all of the information necessary to understand the
request, independent of any requests that may have preceded it.”

41. REST
RP4 : Only a few primitive operations are available.
• “REST components can perform a small set of well-defined methods on a
resource producing a representation to capture the current or intended
state of that resource and transfer that representation between
components. These methods are global to the specific architectural
instantiation of REST—for instance, all resources exposed via HTTP are
expected to support each operation identically.”

42. REST
RP5 : Idempotent operations and representation metadata are encouraged
in support of caching.
• “Caches are important to the goal of reducing latency. The metadata
included in requests and responses permits REST components (such as user
agents, caching proxies) to make sound judgements of the freshness and
lifespan of representations. Additionally, the repeatability (idempotence) of
specific request operations (methods) permits representation reuse.”

43. REST
RP6 : The presence of intermediaries is promoted.
• “Filtering or redirection intermediaries may also use both the metadata and
the representations within requests or responses to augment, restrict, or
modify requests and responses in a manner that is transparent to both the
client and the origin server.”

44. L’évolution de REST

45. Fielding et al. 2017.

46. Fielding et al. 2017.

47. Institute for Software Research, UC Irvine
• Fielding, Roy Thomas. « Architectural Styles and the Design of Network-Based
Software Architectures ». PhD Thesis, University of California, Irvine, 2000.
• Whitehead, Emmet James. « An Analysis of the Hypertext Versioning Domain ».
PhD Thesis, UC Irvine, 2000.
• Oreizy, Peyman. « Open Architecture Sofware: A Flexible Approach to
Decentralized Software Evolution ». PhD Thesis, UC Irvine, 2000.
• Khare, Rohit. « Extending the Representational State Transfer (REST) Architectural
Style for Decentralized Systems ». PhD Thesis, UC Irvine, 2003.
• Erenkrantz, Justin Ryan. « Computational REST: A New Model for Decentralized,
Internet-Scale Applications ». PhD Thesis, University of California Irvine, 2009.
• Michael Martin, Gorlick. « Computational State Transfer: An Architectural Style
for Decentralized Systems ». PhD Thesis, UC Irvine, 2016.

48. CREST : Computational REST (Erenkrantz et al. 2007)
CP1 : The key abstraction of computation is a resource, named by an URL.
CP2 : The representation of a resource is a program, a closure, a continuation, or a
binding environment plus
metadata to describe the program, closure, continuation, or binding environment.
CP3 : CP3 All computations are context-free.
CP4 : Only a few primitive operations are always available, but additional per-
resource operations are also encouraged.
CP5 : The presence of intermediaries is promoted.

49. CREST
CP1 : The key abstraction of computation is a resource, named by an URL.
• “Any computation that can be named can be a resource: word processing or
image manipulation, a temporal service (e.g., “the predicted weather in
London over the next four days”), a generated collection of other resources,
a simulation of an object (e.g., a spacecraft), and so on.”

50. CREST
CP2 : The representation of a resource is a program, a closure, a
continuation, or a binding environment plus
metadata to describe the program, closure, continuation, or binding
environment.
• “CREST introduces a layer of indirection between an abstract resource and
its concrete representation.”

51. CREST
CP3 : All computations are context-free.
• “This is not to imply that applications are without state, but that each in-
teraction contains all of the information necessary to understand the
request, independent of any requests that may have preceded it. Prior
representations can be used to transfer state between computations; for
example, a continuation (representation) provided earlier by a resource can
be used to resume a computation at a later time merely by presenting that
continuation.”

52. CREST
CP4 : Only a few primitive operations are always available, but additional
per-resource operations are also encouraged.
• “Participant A sends a representation p to URL u hosted by participant B for
interpretation. These p are interpreted in the context of operations defined
by u ’s specific binding environment. The outcome of the interpretation will
be a new representation—be it a program, a continuation, or a binding
environment (which itself may contain programs, continuations, or other
binding environments). Of note, a common set of primitives are expected
to be exposed for all CREST resources, but each u ’s binding environment
may define additional resource-specific operations.”

53. CREST
CP5 : The presence of intermediaries is promoted.
• “Filtering or redirection intermediaries may also use both the metadata and
the computations within requests or responses to augment, restrict, or
modify requests and responses in a manner that is transparent to both the
client and the origin server.”

54. Fielding et al. 2017.

55. Quelques mots sur cette évolutions :
• “REST was but one member of a family of architectural styles whose
instantiations had been hiding in plain sight all along and that variations in,
or deviations from, REST were not necessarily flaws or shortcomings but
merely examples of natural and useful, domain-specific variations.”
• “CREST took REST-like systems in a new direction by emphasizing the
primacy of computation over content and relegating content to a side-
effect of computation.”

56. CREST
• “CREST reflects the idiom of computation exchange: it elevates
computations to first-class representations of a resource and designates
context-free state exchange (including computational state reified as
closures, continuation, or binding environments) as the sole form of
information exchange among clients and servers.”
• “CREST resolved several outstanding puzzles in the evolution of the web
including web mashups, session management, the (misplaced) role of
cookies in client/server interactions, and the rationale for time-dependent
resources such as weather forecasts or time-series responses like a stock
ticker.”

57. COAST
• “Many reviewers of CREST observed that exchanging and evaluating
computations (mobile code) among peers appears patently unsafe, leaving
peers open to service theft or denial of service attacks, and easy prey for
hostile takeovers where the peer is used as a launchpad for attacks against
other peers in the network. COmputAtional State Transfer (COAST) also
pursues the idiom of computation exchange but directly addresses these
concerns, this time cast in an architectural style where security and peer
safety are first-order concerns.”

58. Les Règles de COAST
• Services: “All services are computations whose only interactions are the
asynchronous messaging of primitive values, closures, continuations, and binding
environments.”
• Execution: “All computations execute within the confines of some execution site ⟨
E, B ⟩ where E is an execution engine and B a binding environment.”
• Messaging: “Computation x can transmit a message to a computation y only if
there exists a unidirectional communication channel t such that x holds a CURL u
denoting an ingress point of t and y holds an egress point of t.”
• Interpretation: “The interpretation of a message delivered to computation y via
CURL u is y- and u-dependent.”

59. Bibliographie
• Fielding, Roy Thomas. « Architectural Styles and the Design of Network-Based
Software Architectures ». PhD Thesis, University of California, Irvine, 2000.
• Fielding, Roy Thomas, et Richard N. Taylor. « Principled Design of the Modern
Web Architecture ». ACM Transactions on Internet Technology (TOIT) 2, no 2
(2002): 115–150.
• Erenkrantz, Justin R, Michael M Gorlick, Girish Suryanarayana, et Richard N.
Taylor. « From Representations to Computations: The Evolution of Web
Architectures ». In ACM SIGSOFT Symposium on The Foundations of Software
Engineering (FSE’07), 255–264, 2007.
• Fielding, Roy T, Richard N Taylor, Justin R Erenkrantz, Michael M Gorlick, Jim
Whitehead, Rohit Khare, et Peyman Oreizy. « Reflections on the REST
Architectural Style and “Principled Design of the Modern Web Architecture” »,
2017.