Développement web il3

Services web

Applications distribuées

• Motivation : répartir l’exécution sur plusieurs machines
  • Principe : Les composants/services communiquent par le réseau
  • Problèmes : Hétérogénéité systèmes, langages, …
  • Solution : Protocole générique, abstraction différences
  • Exemples : RPC, RMI (java), CORBA, DCOM (MS)
• Utiliser les technologies du web, comme HTTP et XML :
  • indépendantes de la plateforme, éprouvées, largement utilisées
• Système distribué importance de l’architecture :
  • orientée ressource : atome : ressource (donnée) : REST
  • orientée service : atome : service (traitement) : RPC (SOAP)

Service web

• 2 visions :
  • Utiliser les technos web pour développer des applis distribuées
  • Accès pour une application aux services offerts aux humains
• Service web = webapp pour une autre application :
  • Webapps : pour humains, via un navigateur (HTTP + HTML)
  • Services web : aux autres applications (HTTP + XML/JSON)
• Exemples :
  • Applications distribuées pour l’entreprise
  • Mashups d’applications web (exemples)
  • Applications Facebook, API Google
  • IFTTT
• Consommer un service web ≠ Créer un service web

SOAP

• AVANT : Simple Object Access Protocol (obsolète)
• Evolution de XML-RPC, format XML d’envoi de messages
• Architecture Orientée Service (SOA)
• Indépendant du langage et de la plateforme
• Recommandation du w3c depuis 2003
• SOAP = abus de langage, service web WS-* est plus exact
• Spécifications WS-* :
  • spécifications liées aux différents aspects des services web
  • pour déployer un WS : au minimum SOAP + WSDL + UDDI

SOAP

• Structure d’un message SOAP
  • Enveloppe, Entête, Corps, Erreurs
• Squelette :

<?xml version="1.0"?>
<soap:Envelope
     xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
     soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  <soap:Header>  ... </soap:Header>
  <soap:Body>  ... 
    <soap:Fault> ... </soap:Fault>
  </soap:Body>
</soap:Envelope>

SOAP

• Exemple requête/réponse
• Créer un service web WS (SOAP) nécessite WSDL et UDDI :
  • SOAP : Echange de messages XML sur le réseau
  • WSDL : Web Service Description Language
  • UDDI : Universal Description, Discovery and Integration
• WSDL : Description des interfaces des web services
• UDDI : Découverte et inscription aux services web
  • annuaire d’informations sur les services web
  • annuaire d’interfaces de services web décrites en WSDL
• Tutorial WSDL/UDDI w3schools

REST : REpresentational State Transfer

• Style d’architecture sur lequel a été bâti le web
• Architecture Orientée Ressource (ROA)
• Chapitre 5 de la thèse de Roy T. Fielding (fr), 2000
• Parmi les contraintes, une interface uniforme :
  • Identification des ressources (URI)
  • Manipulation des ressources par des représentations
  • Messages autodescriptifs
  • Hypermédia comme moteur de l’état de l’application
• Ressource : information ou moyen d’accès
  • ex. : météo du jour, adresse ajout d’un article à un blog, …
• Représentation : forme donnée à la ressource
  • ex. : page html, fichier PDF, image, flux RSS, fichier sonore, …

REST

• Principes
  • Identifier les ressources avec des URI (noms)
  • Actions déterminées par des méthodes HTTP (verbes)
    • GET : READ (sûre)
    • POST : CREATE
    • PUT, PATCH : UPDATE (idempotente)
    • DELETE : DELETE (idempotente)
  • Les liens hypertextes permettent de représenter le contenu : navigation
  • Les types MIME determinent la représentation de la ressource
• Rappel
  • Sûreté : Etat de la ressource (contenu) inchangé
  • Idempotence : plusieurs appels donnent le même résultat

REST

• L’appel d’une ressource avec des verbes différents produira un résultat différent :

• Laravel, Django, Rails, … sont RESTful !

Niveaux de maturité de Richardson

• 0: Plain Old Xml (POX)
  • Utilisation de HTTP pour faire du RPC
• 1: Ressources
  • Ressources identifiées par URI
• 2: Verbes HTTP
  • Respect des propriétés des verbes HTTP
• 3: Hypertext As The Engine Of Application State (HATEOAS)
  • Les états suivants sont documentés dans la réponse (<link>)

SOAP vs REST

• webservice : exposer son API en REST ou SOAP ?
• SOAP (WS-*)
  • hérité du monde de l’entreprise
  • plus de code pour manipuler la requête et générer la réponse
  • plus flexible, extensible (namespace)
  • valider requêtes depuis WDSL
  • nécessité d’un framework (ex: nuSOAP en PHP)
• REST
  • hérité du web
  • plus facile et rapide à utiliser
  • plus lisible et plus compact
  • maintenance plus facile
  • meilleure tolérance aux pannes

Pour aller plus loin…

• Références
  • SOAP, WSDL, UDDI, REST, The WSIO
  • Des services web RESTful, Une apologie de REST (recommandés)
  • REST et architectures orientées service, Présentation ROA
  • The RESTful cookbook, How important is HATEOAS (stack overflow)
• Exemples de services web :
  • Google, Yahoo, Flickr, Twitter, Spotify…
  • APIary : Aide au design d’une API REST
  • Tests : Postman, Hoppscotch, Ping-API, autres
• GraphQL
  • est destiné à devenir la prochaine évolution des apis REST utilisant JSON. Initié par Facebook, Github permet également d’en faire usage.

Sources