Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Cours sur REST

Cours donné à l'UTT le 28 mars 2018 sur le style d'architecture REST.

(correction : slide 14, lire "1995")

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Cours sur REST

  1. 1. LO10 – UTT Cours sur REST Alexandre Monnin (Origens Medialab)
  2. 2.  Le Web est-il un hypertexte? F Le réseau comme hypertexte
  3. 3. Bien sûr! • protocole : “HyperText Transfer Protocol” (HTTP) • langage : “HyperText Markup Language” (HTML) F
  4. 4. Bien sûr ! Le « Web » fut presenté lors de la 3e conférence ACM Hypertext en 1991 (San Antonio, Texas) F
  5. 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. 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. 7. REST et l’architecture du Web
  8. 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. 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. 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. 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. - 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. 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. 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. 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. 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. 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. 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. 19. Roy T. Fielding/ Tim Berners-Lee Credits Paul Downey
  20. 20. Saint Paul/ Jésus (?)
  21. 21. REST = Transfert d’états représentationnels ▪la ressource ▪l’état de la ressource ▪l’état représentationnel ou représentation de la ressource - 22 « … »
  22. 22. “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)
  23. 23. 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)
  24. 24. Un Web de documents ? Non ! Un Web de Ressources ! « … »
  25. 25. Dé-spatialiser les URI (adresses vs identifiants)
  26. 26. Quelques conséquences
  27. 27. "Resources are angels, URIs pins" (Larry Masinter)
  28. 28. Web Sémantique : Principe AAA  Anyone can say anything about Anything Web : Principe ADA  Anyone Can designate Anything (any Resource)
  29. 29. Hypertexte ? http://roy.gbiv.com/untangled/2008 /rest-apis-must-be-hypertext-driven
  30. 30. Les principales propriétés du style REST
  31. 31. “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)
  32. 32. Fielding et al. 2017.
  33. 33. Fielding et al. 2017.
  34. 34. Fielding et al. 2017.
  35. 35. 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.
  36. 36. 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.”
  37. 37. 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.”
  38. 38. 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.”
  39. 39. 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.”
  40. 40. 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.”
  41. 41. 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.”
  42. 42. L’évolution de REST
  43. 43. Fielding et al. 2017.
  44. 44. Fielding et al. 2017.
  45. 45. 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.
  46. 46. 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.
  47. 47. 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.”
  48. 48. 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.”
  49. 49. 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.”
  50. 50. 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.”
  51. 51. 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.”
  52. 52. Fielding et al. 2017.
  53. 53. 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.”
  54. 54. 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.”
  55. 55. 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.”
  56. 56. 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.”
  57. 57. 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.

×