Concepts Ressources








télécharger 59.63 Kb.
titreConcepts Ressources
date de publication02.02.2018
taille59.63 Kb.
typeDocumentos
ar.21-bal.com > droit > Documentos
RESTFUL Web Services
  1. Architecture orientée ressource


ROA ou Resource Oriented Architectures est une structure de conception supportant l'interconnexion de réseaux de ressources. Une ressource, dans ce contexte, désigne toute entité qui peut être identifié et attribué dans un URI (Uniform Resource Identifier).

Voici donc les 4concepts et les 4propriétés décrivant une architecture orientée ressource :
    1. Concepts

      1. Ressources


Une ressource est quelque chose d'assez important pour être référencé comme étant une chose en elle-même, créer un lien hypertexte vers elle, faire ou réfuter des affirmations à son sujet, rechercher ou mettre en mémoire cache une représentation la concernant, l'inclure en partie ou dans son ensemble en la référençant dans une autre représentation, l'annoter ou encore effectuer d'autres opérations. [5]

Généralement, une ressource est quelque chose qui peut être stocké sur un ordinateur, un document, une ligne dans une base de données, ou le résultat de l'exécution d'un algorithme. [5]
      1. URI (Uniform Resource Identifier)


Mais pour qu'une ressource soit connue, il faut qu'elle soit accessible et pour ça on a créé les URI qui sont à la fois le nom et l'adresse d'une ressource, sans URI pas de ressource. C'est ce qui fait la force du Web (HTTP), et ce qui lui a permis d'écraser une bonne partie des autres protocoles. Aujourd'hui tout passe par ce protocole au détriment des autres, on télécharge via un navigateur et non un client FTP par exemple. [5]

L'un des points importants de l'architecture orientée ressource est qu'une URI doit être descriptive. On doit savoir ce qui se cache derrière une URI rien qu'en la lisant, par exemple en allant sur http://www.monsite.com/liens/ vous savez que vous allez accéder à une page listant des liens.

Une ressource doit au moins avoir une URI mais rien n'empêche une ressource d'avoir plusieurs URI.
      1. Représentation des ressources


Une représentation est une encapsulation de l'information (état, données, ou balisage) de la ressource, encodée en utilisant un format tel que XML, JSON, ou HTML.

La plupart des sites et applications utilisent généralement format HTML avec text/html comme type de média. Et il existe d'autres types, tels que application/xml pour le format XML ou application/Json pour le format JSON. [6]
      1. Relation entre les ressources


Les représentations ne contiennent bien souvent pas seulement des données mais aussi des liens vers d'autres ressources. Résume bien le fait que nous naviguons sur internet grâce aux liens entre les ressources.
    1. Propriétés

      1. Adressage


Adressabilité dit que chaque information intéressante que le serveur peut fournir, doit être exposée comme une ressource, et compte tenu de sa propre URI.

Comme les ressources sont identifiées par leurs URI, ça consiste généralement à fournir une liste d'URI possibles. Celles-ci pouvant être infinies comme par exemple dans le cas de Google : http://www.google.com/search?q=REST. Grâce à cette propriété, on peut indiquer une adresse à quelqu'un sans lui dire : va sur google.com et taper « REST » dans le formulaire. [5]
      1. Sans état (Stateless)


Chaque requête du client vers le serveur doit contenir toutes les informations nécessaires pour que cette demande soit comprise, et elle ne peut tirer profit d'aucun contexte stocké sur le serveur. L'état de la session est donc entièrement détenu par le client. [7]

Chaque nouvelle page affichée contient toutes les informations nécessaires pour afficher la ressource appropriée ou effectuer les traitements nécessaires, les requêtes ne doivent pas avoir d'ordre prédéfini et sont déconnectées les unes des autres. Chaque requête est totalement déconnectée à partir des autres. Le client peut faire des requêtes pour ces ressources n’importe quel nombre des fois, dans un ordre quelconque. De cette façon, le serveur n'a jamais besoin de connaître l'état du client, il ne sait même pas où il est, il sait juste qu'une requête arrivant avec tels paramètres doit restituer telles données. [5]
      1. Connecté


Cette propriété est directement issue du concept des liens évoqué ci-dessus. Les ressources doivent s'inter-lier dans leurs représentations respectives.
      1. À interface uniforme


Et cette interface provient des verbes HTTP Si l'on considère les 4 verbes les plus intéressants, bref rappel tout de même : GET, POST, PUT, DELETE. Et nous allons expliquer en détails ultérieurement.

Il existe aussi les verbes HEAD et OPTIONS qui sont utiles :

HEAD : permet de récupérer uniquement les métadonnées ;

OPTIONS : permet de connaître les verbes autorisés pour une URI donnée.
  1. Web services RESTful

    1. Architecture REST

      1. Historique


REST est l'acronyme de "REpresentational State Transfer" inventé par Roy T. Fielding dans sa dissertation "an architecture style of networked systems". REST décrit les caractéristiques du web qui en ont fait son succès. L'explication de la signification de REST telle que donnée par Roy T. Fielding est la suivante : ‘Representational State Transfer’ évoque l'image du fonctionnement d'une application web bien construite : « un réseau de pages web où l'utilisateur progresse dans l'application en cliquant sur des liens (transition entre états) ce qui provoque l'affichage de la page suivante (représentant le nouvel état de l'application) à l'utilisateur qui peut alors l'exploiter. » [8]
      1. Définition


REST est un style d'architecture, pas un standard. Il n'existe donc pas de spécifications de REST. Est un style d'architecture réseau pour web services qui met l'accent sur la définition de ressources identifiées par des URI, et utilise les messages du protocole HTTP pour définir la sémantique de la communication client/serveur.

Roy T. Fielding dit dans sa Thèse de doctorat : REST est un modèle hybride dérivé de plusieurs modèles basés sur les concepts réseau.
      1. Différences entre SOA (basé sur SOAP) et REST


L’architecture REST et SOA (basé sur SOAP) sont utilisées pour fournir des services web. Contrairement à ce que l’acronyme SOAP laisse entendre (Simple Object Access Protocol), REST est souvent utilisé lorsque la simplicité de mise en œuvre est recherchée. [4]

L’architecture REST est :

  • Lisible (pas d’enveloppe XML superflue)

  • Facile à tester (un navigateur suffit) tout en étant facile de mise en œuvre,

  • Aucun outil coûteux nécessitent d'interagir avec le service web (un script PHP classique peut souvent être considéré comme RESTful)

  • Efficace (SOAP utilise XML pour tous les messages, REST peut utiliser des formats de message plus petits)

  • La rapidité (pas de traitement vaste requis) et plus proche à d'autres technologies Web en philosophie de conception.

SOAP reste toutefois intégré dans de nombreux outils de développements (possibilité d’export de classes en web services, possibilité de génération automatique de clients à partir des WSDL) et permet des contrôles forts sur les types de données attendus.

Voici un exemple d’une enveloppe SOAP :





xmlns:soap="http:// www.w3.org/2001/12/soap-envelope"

soap:encoding>




GetActualite>


ActualiteID>12
ActualiteID>


GetActualite>








Et avec REST, La requête sera décrire comme suite :


http://127.0.0.1:8090/serviceEtud/actualite/12




Nous notons il y a seulement une URL. Cette URL est envoyée au serveur en utilisant une simple requête GET, et n’est pas appelé la méthode "GetActualite", mais simplement "actualite".
      1. Les contraintes de REST défini par Roy T. Fielding


Voici les six (6) contrainte de REST sont défini par Roy T. Fielding [7] :

  • Client-Serveur :

Les responsabilités sont séparées entre le client et le serveur. L'interface utilisateur est séparée de celle du stockage des données. Cela permet aux deux d'évoluer indépendamment.

  • Sans état (Stateless) :

Chaque requête d'un client vers un serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le client et le serveur.

Le serveur envoie une réponse qui donne l'information sur la propension de cette réponse à être mise en cache, comme la fraîcheur, sa date de création, si elle doit être conservée dans le futur. Cela permet à des serveurs mandataires de décharger les contraintes sur le serveur et aux clients de ne pas faire de requêtes inutiles. Cela permet également d'améliorer l'extensibilité des serveurs.

  • Interface uniforme :

Toutes les ressources sont accessibles par une interface générique (par exemple, HTTP GET, POST, PUT, DELETE).

  • Un système hiérarchisé par couche :

Les états de l'application sont identifiés par des ressources individuelles. Toute l'information n'est pas envoyée dans une seule ressource unique. Les requêtes/réponses entre le client et le serveur augmentent et donc peuvent faire baisser la performance d'où l'importance de la mise en cache, etc. Le bénéfice est que cela rend beaucoup plus flexible l'évolution du système.


  • Code à la demande (facultatif) :

Exécution de scripts côté client obtenus par le serveur. Cela permet de rendre le client plus léger et plus générique. Permet l’extension des fonctionnalités d’un client par le biais de téléchargement et d’exécution de code sous forme d'applet ou de scripts, cela simplifie les clients en réduisant le nombre de fonctionnalités qu’ils doivent mettre en œuvre par défaut.

    1. Différence entre REST et RESTful


Régulièrement, lire REST ou RESTful lorsque la technologie est abordée. En bref, il n’y a aucune différence, RESTful est simplement l’adjectif qui qualifie une architecture de type REST.

4.3. Principe des web services RESTful

4.3.1. Méthodes HTTP


Ainsi, généralement pour une ressource, il y a 4 opérations possibles et HTTP propose les verbes correspondant :

  • Créer (Create) => POST

  • Afficher (Read) => GET

  • Mettre à jour (Update) => PUT

  • Supprimer (Delete) => DELETE

Exemple d’URI pour une ressource donnée (une Actualité par exemple), pour ajouter ou modifier ou supprimer une ressource on peut utiliser la méthode GET de manière suivante par exemple :

  1. GET 127.0.0.1:8090/serviceEtud/actualite/afficher?id=7

  2. GET 127.0.0.1:8090/serviceEtud/actualite/supprimer?id=7

  3. GET_127.0.0.1:8090/serviceEtud/actualite/ajouter?titre=Constantine2015&texte=capitaleDeLaCultureArabe2015…

Dans les cas « a » et « b » nous devons modifier les méthodes HTTP, pour respecter l’architecture REST et l’URI devenu descriptif :

GET127.0.0.1:8090/serviceEtud/actualite/7- Afficher l’actualité numéro 7

DELETE127.0.0.1:8090/serviceEtud/actualite/7- Supprimer l’actualité 7

Le cas « » il y a un problème ! , il faut ne pas faire circuler des informations clairement sur le réseau. La simple moyen pour éviter ce problème et de envoyer les noms et les valeurs des paramètres de la requête HTTP dans format JSON ou balise XML à partir du « Request body ».

Par exemple le cas « c » ajouter actualité (utilisation de la méthode POST)


POST /serviceEtud/actualite HTTP/1.1

Host :127.0.0.1 :8080

Content-Type: application/json

{

"titre"="constantine2015"

"texte"= "capitale de la culture arabe 2015"

}




Request Header



RequestBody




      1. URI comme identifiant des ressources


REST se base sur les URI (Uniform Resource Identifier) afin d’identifier une ressource. Ainsi une application se doit de construire ses URI de manière précise, en tenant compte des contraintes REST. Il est nécessaire de prendre en compte la hiérarchie des ressources et la sémantique des URL pour les éditer.

En construisant correctement les URI, il est possible de les trier, de les hiérarchiser et donc d’améliorer la compréhension du système. [9]

L’URL suivante peut alors être décomposée logiquement :

/serviceEtud/etudaint tous les étudiants

/serviceEtud/etudaint/39  un étudiant

/serviceEtud/etudaint/39/message  tous les messages d’étudiant

/serviceEtud/etudaint/39/message/12un message d’étudiant.

4.3.3. Représentation des ressources


Le principe en pratique est de passer de la représentation utilisée en interne, que ce soit sur le client ou le serveur, a la représentation utilisée dans le message HTTP, requête ou réponse.

Pour les Web Services RESTful, les encodages les plus utilises sont XML et JSON.

JSON est l'acronyme de JavaScript Object Notation. C'est un format texte qui permet de représenter des données et de les échanger facilement à l'instar d'XML,

Ce sous ensemble de JavaScript permet de décrire le modèle objet de JavaScript. Deux types de structures sont disponibles :

  • Objet : une collection de paire nom/valeur, i.e. un tableau associatif.

  • Tableau : une liste ordonnée de valeurs.

La syntaxe est celle de JavaScript, simpliste. Voici par exemple la description d'un étudiant avec format JSON :


[ {

"id":7,

"nom":"Bendahi",

"prenom": "mohamed",

"sexe": "homme",

"date_naissanse": "10/10/1991",

"telephone": "066666666",

"adresse":"Biskra",

"email":"bmohamed1991@gmail.com",

}]




4.3.4. Relation entre ressources


Les liens d’une ressource vers une autre ont tous une chose en commun : ils indiquent la présence d’une relation. Il est cependant possible de la décrire afin d’améliorer la compréhension du système. Pour expliciter cette description et indiquer la nature de la relation, l’attribut rel doit être spécifié sur tous les liens. Ainsi l’IANA (Internet Assigned Numbers Authority) donne une liste de relation (self, next, edit, last, payment, content…) [9].
  1. Débat SOAP vs REST

    1. Avantage des Web Services SOAP


Le langage XML est un langage textuel facilement compréhensible par un être humain. Cela permet alors de pouvoir détecter plus facilement les erreurs de transmissions et rendre ainsi les débogages de la chaîne de communication plus simple.

SOAP est assez ouvert pour s'adapter à différents protocoles de transport, indépendant de la plate-forme et du langage.

Les capacités d'auto-description et de découverte des web services permettent de ne pas être dépendant d'un unique fournisseur pour effectuer une même action (en théorie). Cela réduit alors les dépendances entre clients et fournisseurs, et favorise ainsi la récupération en cas d'erreur, de manière dynamique. [3]

SOAP peut opérer au-dessus d’autres protocoles que HTTP, en particulier sur des protocoles permettant des communications asynchrones telles que SMTP, JMS, MSMQ et MQSeries.

Lorsqu’il est utilisé en conjonction avec des spécifications WS-*, SOAP permet déprendre en compte des aspects liés à la sécurité, la fiabilité et l’adressage et routage de messages. Bien sûr, il serait possible de faire de même en utilisant l’approche REST, mais les standards et l’infrastructure correspondant ne sont pas en place.

SOAP est plus adapté à l’intégration des applications et des systèmes isolés.

    1. Inconvénients des Web Services SOAP


HTTP est utilisé uniquement comme moyen de transport. Les seuls messages utilisés de HTTP sont GET et POST. Chaque web service dispose d'une interface spécifique, encapsulé directement dans HTTP (pour le cas simple des XML-RPC) ou dans SOAP, et dans ce dernier cas décrite en XML par le langage WSDL.

La mise en œuvre réelle est complexe, les normes volumineuses et difficiles à véritablement maitriser.

La façon la plus répandue d’utiliser SOAP consiste à s’appuyer sur le protocole HTTP en utilisant la liaison SOAP-HTTP. Dans cette liaison, il est possible d’associer plusieurs opérations à la même URL (toutes les opérations d’un service peuvent être fournies sur une seule URL. Une application donnée peut alors appeler chacune de ces opérations en utilisant la méthode http POST, et en incluant le nom de l’opération concernée par la requête dans l’en-tête http « SOAPAction ».

Cette approche, ainsi que d’autres caractéristiques de SOAP, ont fait l’objet de nombreuses critiques. Les arguments principaux mis en avant contre SOAP reposent sur le fait que : (i) il rajoute peu de fonctionnalités au-dessus de ce qu’il est déjà possible de faire avec HTTP et XML; et (ii) en associant plusieurs opérations à une même URL, il rend difficile, voire impossible, l’utilisation de l’infrastructure de «caching »associée au protocole HTTP, qui constitue sans doute l’un des points forts de HTTP.
    1. Avantages et inconvénients des RESTful WSs


Dans REST, chaque opération d’un service est associée à une URL distincte et l’accès à chaque URL peut être réalisé en utilisant l’une des quatre méthodes fournies par HTTP : POST, GET, PUT et DELETE.

Le contenu des messages est alors encodé en XML (ou JSON), et la distinction entre en-tête et contenu de message est laissée à la charge des applications qui requièrent cette distinction. Le résultat est un ensemble de conventions plus simples que celles de SOAP, et la possibilité d’utiliser des bibliothèques existantes pour l’échange de messages sur HTTP, éliminant ainsi le besoin de plates-formes implantant SOAP, qui dans certains cas peuvent être considérées comme étant plus « lourdes » et plus difficiles à utiliser.

Plusieurs services Web populaires disponibles à l’heure actuelle utilisent l’approche REST (appelée aussi « XML sur HTTP » (eBay, Amazon,..).

Conclusion

Le débat SOAP vs. REST est encore ouvert et les avis divergent considérablement dans la communauté. Les avantages et désavantages relatifs de SOAP et REST peuvent être résumés comme suit :

REST ne requiert pas d’infrastructure spécifique pour le développement et l’exécution des services Web. Il repose sur l’infrastructure HTTP existante, qui a fait ses preuves dans le contexte des applications HTML classiques. De nombreux outils de programmation d’applications au-dessus de HTTP existent, et peuvent être combinés avec des outils de manipulation de documents XML pour construire des services Web « style REST ». Dans le cas de SOAP, il est nécessaire d’utiliser des outils spécifiques qui sont parfois difficiles à déployer et n’ont pas complètement fait leurs preuves.

En conclusion, l’approche REST est viable (voire préférable) dans le cas de services Web avec les caractéristiques suivantes : (i) ils n’ont besoin d’être exposés que sur http ou HTTPS ; (ii) les communications asynchrones (et donc l’adressage explicite) ne sont pas requises ; (iii) ils ne requièrent pas de garanties de sécurité au delà de celles offertes par HTTPS ; et (iv) la fiabilité peut facilement être traitée au niveau des applications.

similaire:

Concepts Ressources iconGestion des ressources humaines
«corps social» Dans cette perspective la Gestion des ressources humaines doit tendre à améliorer la communication transversale, tout...

Concepts Ressources iconConcepts et Techniques

Concepts Ressources iconConcepts, actions et outils linguistiques

Concepts Ressources iconBts se r V ice s I n f or m a t I qu e s a u X o r g a n I s at I on s
Dans tous les cas, les candidats doivent se munir des outils et ressources techniques nécessaires au déroulement de l’épreuve. Ils...

Concepts Ressources icon1. Concepts de base de l'impression sous Unix

Concepts Ressources iconSciences Humaines 9 – Les concepts clés (L à J)

Concepts Ressources iconPartie theorique : définitions des concepts utilisés au sein de ce mémoire professionnel 5

Concepts Ressources iconQuestion de cours + perception des nvelles technologies, les concepts...

Concepts Ressources iconI concepts généraux liés aux retables
«retable doré à la feuille» c’est-à-dire sur lequel des feuilles d’or ont été appliquées

Concepts Ressources iconCadre général
«Conduite de Projet» dispensé au Master 1 stic. L’objectif est de mettre en application les concepts du cours de cette ue en suivant...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com