Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Corporate Headquarters EMEA Headquarters Asia-Pacific Headquarters 100 Californ

Corporate Headquarters EMEA Headquarters Asia-Pacific Headquarters 100 California Street, 12th Floor San Francisco, California 94111 York House 18 York Road Maidenhead, Berkshire SL6 1SF, United Kingdom L7. 313 La Trobe Street Melbourne VIC 3000 Australia Copyright © 2009 Marco Cantu. All Rights Reserved. REST et Delphi 2010 Un livre blanc de Marco Cantù (http://blog.marcocantu.com) Novembre 2009 SYNTHÈSE EXÉCUTIVE La nouvelle architecture REST (« Representational State Transfer ») a un impact significatif sur l'ensemble de l‟industrie et la plupart des nouveaux services Web « grand-public » conçus par les acteurs majeurs du secteur (Google, Yahoo, Amazon et aussi Microsoft) utilisent cette technologie pour partager et fusionner des informations multisources. L‟implémentation de l‟architecture REST ne s‟appuyant que sur des technologies simples (HTTP et XML), Delphi lui a toujours offert un support de choix ; sa dernière version (Delphi 2010) le complète d‟une prise en charge spécifique pour le développement de serveurs REST – dans l‟infrastructure DataSnap. Cette étude revient sur les technologies REST impliquées dans une perspective Delphi et démontre comment créer des applications clientes pour des sites Web populaire et comment construire des serveurs REST avec le support spécifique offert par Delphi 2010. INTRODUCTION La dernière décennie a vu l‟explosion du Web et plus récemment l‟apparition du Web 2.0. Les interactions automatiques entre sites Web, sites et applications clientes ou entre sites Web et bases de données métier sont en revanche plus récentes et exigent généralement des interconnexions globales parfois difficiles à comprendre. La vitesse de déplacement et de rafraîchissement des données sur le Web est devenue bien supérieure à la capacité de consultation de chacun ; d‟où une forte demande pour les programmes permettant de localiser, suivre et superviser des informations multisources (donnes commerciales, informations financières, communautés en ligne, campagnes marketing, etc.). POURQUOI DES SERVICES WEB ? L‟émergence des services Web permet d‟envisager de nouveaux modes d‟utilisation d‟Internet par les entreprises... Naviguer sur différentes pages pour passer une commande est suffisant pour les environnements B2C (business-to-consumer) mais certainement pas pour les contextes B2B (business-to-business) plus sophistiqués. Par exemple, il est généralement très ergonomique pour un utilisateur de rechercher et acheter des livres sur un site marchand ; en revanche, si vous dirigez une librairie en ligne passant des centaines de commandes par jour, la même approche serait totalement inefficace – surtout si d‟autres applications déterminent les réapprovisionnements en fonction des ventes… Ressaisir ces données dans une autre application serait en effet complètement ridicule... Les services Web ont (ou du moins avaient à l‟origine) précisément pour vocation de résoudre ce problème. Par exemple, lorsque le programme crée automatiquement une demande de réapprovisionnement de livres ; il l‟adresse ensuite à un service Web qui retourne immédiatement les informations sur la commande. L‟étape suivante consistant par exemple à demander un numéro de suivi de livraison. À ce stade, le programme peut utiliser un autre service Web pour suivre la livraison jusqu‟à sa destination – et informer le client sur le temps d‟attente. À la livraison, le programme peut également adresser une information (par SMS/Pager/Twitter) aux personnes ayant des commandes en attente, déclencher un paiement avec un service Web bancaire, etc. Cet exemple donne une bonne idée de la cinématique générale : les services Web sont à l‟interopérabilité des systèmes ce que le Web et l‟e-mail sont aux interactions entre individus... Le périmètre des services Web est extrêmement étendu et implique de multiples technologies et standards. Je me concentrerai donc sur l‟implémentation Delphi sous-jacente et sur les aspects techniques des services Web – sans aborder leurs implications métier au sens large. Delphi for Win32 propose des solutions très sophistiquées pour prendre en charge les services Web – dérivées initialement de SOAP – et qui peuvent aujourd‟hui être facilement étendues à travers des composants HTTP et REST. TECHNOLOGIES CLÉS DES SERVICES WEB : SOAP ET REST Le concept de service Web est en soi plutôt abstrait. Technologiquement, deux solutions attirent principalement les développeurs : le standard SOAP (Simple Object Access Protocol, voir http://www.w3.org/TR/soap/) et REST (Representational State Transfer) avec sa variante XML-RPC (XML-Remote Procedure Call). Ces deux solutions utilisent généralement HTTP comme protocole de transmission (bien qu‟il existe des alternatives) et XML (ou JSON) pour les déplacements bidirectionnels de données. Le protocole HTTP standard permet au serveur Web de gérer les requêtes et de faire transiter les paquets de données à travers les pare-feux. Ce livre blanc n‟aborde pas les détails de SOAP et porte exclusivement sur REST. Je commencerai par définir les fondations théoriques, je présenterai ensuite un exemple simple de serveur et de client, je reviendrai en détail sur le développement de clients REST pour des services Web REST particulièrement populaires et je conclurai sur le support serveur REST offert par Delphi 2010 – en tant qu‟extension de l‟architecture DataSnap. LES CONCEPTS SOUS-JACENTS DE REST (REPRESENTATIONAL STATE TRANSFER) Même si l‟idée générale de REST est relativement ancienne, sa formalisation et la théorie sous-jacente sont plus récentes. Il convient avant tout de souligner qu‟il n‟existe pas de standard REST formel. REST est l‟acronyme de « Representational State Transfer », initialement employé par Roy Fielding dans son mémoire de Ph.D. de 2000, ce terme a été rapidement adopté pour désigner les accès aux données par le Web à travers HTTP et des URL – plutôt qu‟en s‟appuyant sur le standard SOAP. Initialement, le terme REST se référait à un style architectural décrivant la relation entre un navigateur et un serveur Web. L‟idée étant que lorsqu‟on accède à une ressource Web (avec un navigateur ou une application cliente spécifique) le serveur retourne une représentation de ladite ressource (page, image, données brutes, etc.). Le client recevant cette représentation est défini dans un état donné ; lorsqu‟il accède à d‟autres informations ou pages (par exemple via un lien) son état change lors du transfert. Dans les propres mots de Roy Fielding : « REST retranscrit la rationalité de comportement d’une application Web bien conçue : un réseau de pages Web (ou machine d’état virtuelle) où l’utilisateur progresse à travers l’application en sélectionnant des liens (transitions d’état) pour afficher la page suivante (état applicatif suivant) transféré et restitué à l’utilisateur pour manipulation. » POINTS CLÉS DE L‟ARCHITECTURE REST Si REST est bien une architecture (ou mieux : un « style architectural »), ce n‟est clairement pas un standard (bien qu‟il s‟appuie sur des standards existants : HTTP, URL, différents types de formats pour les données, etc.). Alors que SOAP se superpose à HTTP et XML ; les architectures REST utilisent HTTP et XML (et d‟autres formats) exactement comme ils sont :  REST utilise des URL pour identifier une ressource serveur (SOAP utilise une seule URL pour plusieurs requêtes, détaillées dans l‟enveloppe SOAP). On retiendra que l‟URL identifie une ressource et non une opération sur la ressource.  REST recourt à des méthodes HTTP pour indiquer les opérations à effectuer (récupérer ou HTTP GET, créer ou HTTP PUT, mettre à jour ou HTTP POST et effacer ou HTTP DELETE)  REST utilise des paramètres HTTP (comme paramètres de requête et POST) pour fournir des informations supplémentaires au serveur.  REST s‟appuie sur HTTP pour l‟authentification, le cryptage et la sécurité (avec HTTPS)  REST retourne les données sous forme de documents bruts en différents formats Mime (XML, JSON, images, etc.) Dans ce type de scénario de nombreux éléments architecturaux doivent être pris en considération. REST exige que les systèmes soient :  Client/serveur par nature (pas de SGBDR à ce niveau)  Sans état  Adaptés à la gestion en cache (la même URL doit retourner les mêmes données si elle est appelée deux fois en séquence – sauf si les données ont changé côté serveur), afin de permettre l‟insertion de serveurs de proxy et de cache entre le client et le serveur. Le corollaire est que les opérations GET ne doivent pas avoir d‟effets induits. La théorie de REST est naturellement plus complète que la présentation précédente qui constitue cependant un bon point de départ. Les exemples pratiques qui suivent sont accompagnés du code Delphi et devraient clarifier ces concepts élémentaires. DELPHI ET LES TECHNOLOGIES REST Comme nous l‟avons vu, il n‟existe pas de standard REST et le développement REST n‟exige aucun outil spécifique ; cependant, quelques standards connexes méritent une brève description (sachant que chacun d‟entre eux pourrait faire l‟objet une étude à part entière…). Une fois encore, nous envisagerons ces technologies sous l‟angle de la prise en charge par Delphi. HTTP (CLIENT ET SERVEUR) Le protocole HTTP (HyperText Transfer Protocol) est au cœur du Web et ne nécessite pas une plus ample présentation ; notons simplement qu‟il peut être utilisé avec des navigateurs mais aussi avec n‟importe quelle autre application. Avec Delphi, le moyen le plus simple d‟écrire une application cliente utilisant HTTP consiste à répondre sur le composant client IdHttp (ou Indy HTTP). En appelant la méthode GET de ce composant en fournissant une URL comme paramètre, il est possible de récupérer le contenu de n‟importe quelle page Web et de nombreux serveurs REST. Il est parfois nécessaire de définir d‟autres propriétés pour fournir des uploads/s1/ delphi-2010-rest-wp-marco-cantu-fr.pdf