Construire des services Web REST la Voie


Original: http://www.xfront.com/REST-Web-Services.html

Roger L. Costello

Je vais d’abord donner une brève introduction à REST, puis décrire comment construire des services Web dans le style REST.

Qu’est-ce que REST?

REST est un terme inventé par Roy Fielding dans son doctorat thèse [1] pour décrire un style d’architecture des systèmes en réseau. REST est un acronyme pour Representational State Transfer.

Pourquoi est-il appelé Representational State Transfer?
Le Web est composé de ressources. Une ressource est un article d’intérêt. Par exemple, le Boeing Aircraft Corp peut définir une ressource 747. Les clients peuvent accéder à cette ressource avec l’URL suivante:

http://www.boeing.com/aircraft/747

Une représentation de la ressource est renvoyée (par exemple, Boeing747.html). La représentation met l’application cliente dans un état. Le résultat du client traversant un lien hypertexte dans Boeing747.html est une autre ressource est accédée. La nouvelle représentation met l’application client dans un autre état​​. Ainsi, les modifications de l’application client (transferts) d’état à chaque représentation de la ressource -> Representational State Transfer!

Voici l’explication de Roy Fielding de la signification de Representational State Transfer:

“Representational State Transfer est destiné à évoquer une image de la façon dont une application Web bien conçu comporte: un réseau de pages Web (un état ​​de la machine virtuelle), où l’utilisateur progresse grâce à une application en sélectionnant des liens (transitions d’état), résultant en la page suivante (ce qui représente l’état suivant de l’application) étant transféré à l’utilisateur et rend leur utilisation “.

Motivation pour REST
La motivation pour REST était de capturer les caractéristiques du Web qui a réussi le Web. Par la suite ces caractéristiques sont utilisés pour guider l’évolution du Web.

REST – un style architectural, pas une norme

REST n’est pas une norme. Vous ne verrez pas de mettre le W3C une spécification REST. Vous ne verrez pas IBM ou Microsoft ou Sun vente la boîte à outils du développeur REST. Pourquoi? Parce que REST est juste un style architectural. Vous ne pouvez pas refouler ce style. Vous ne pouvez le comprendre, et de concevoir vos services Web dans ce style. (Analogue à l’architecture client-serveur. Aucune norme client-serveur.)

Bien que REST n’est pas une norme, il n’utilise normes:

  • HTTP
  • URL
  • XML / HTML / GIF / JPEG / etc (ressources Représentations)
  • text / xml, text / html, image / gif, image / jpeg, etc (types MIME)

Le système REST classique
Le Web est un système REST! Beaucoup de ces services Web que vous avez utilisé ces nombreuses années – Services de livre-commande, les services de recherche, de services en ligne Dictionnaire, etc – sont des services Web REST. Hélas, vous avez utilisé REST, la création de services REST et vous ne savez même pas.

REST est préoccupé par la «grande image» du Web. Il ne traite pas des détails de mise en œuvre (par exemple, en utilisant des servlets Java ou CGI pour mettre en œuvre un service Web). Alors regardons un exemple de création d’un service Web à partir de la «grande image» perspective REST.

Pièces Web Services Depot
Parts Depot, Inc (société fictive) a déployé des services web pour permettre à ses clients de:

  • obtenir une liste des pièces
  • obtenir des informations détaillées sur une partie particulière
  • présenter un bon de commande (PO)

Prenons comment chacun de ces services sont mis en œuvre dans un mode RESTful.

Obtenez la liste de pièces
Le service web met à disposition une URL à une ressource de la liste des pièces. Par exemple, un client utilise cette adresse pour obtenir la liste des pièces:

http://www.parts-depot.com/parts

Notez que le “comment” le service Web génère la liste des pièces est complètement transparent pour le client. Tout le client sait que si il / elle soumet l’URL ci-dessus puis un document contenant la liste des pièces est retourné. Depuis la mise en œuvre est transparente pour les clients, Parts Depot est libre de modifier l’implémentation sous-jacente de cette ressource sans impact sur les clients. C’est couplage lâche.

Voici le document que le client reçoit:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[Supposons que, grâce à la négociation de contenu du service déterminé que le client veut la représentation au format XML (pour le traitement machine-to-machine).] Notez que la liste des pièces a des liens pour obtenir des informations détaillées sur chaque partie. C’est un élément clé de REST. Les transferts de clients d’un état à l’autre en examinant et en choisissant parmi les URL de substitution dans le document de réponse.

Obtenez détaillée des données Partie
Le service web met à disposition une URL pour chaque ressource de partie. Exemple, voici comment un client demande une partie 00345:

http://www.parts-depot.com/parts/00345

Here’s the document that the client receives:

 

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Encore une fois observer comment ces données est lié à encore plus de données – le cahier des charges de cette partie peut être trouvé en parcourant le lien hypertexte. Chaque document de réponse permet au client de forer vers le bas pour obtenir des informations plus détaillées.

Envoyer PO
Le service web met à disposition une URL à soumettre un bon de commande. Le client crée une instance de document PO qui est conforme au schéma de PO qui Parts Depot a conçu (et publié dans un document WSDL). Le client soumet Po.xml que la charge utile d’un HTTP POST.

Le service de PO répond à la requête HTTP POST avec une URL à la PO soumis. Ainsi, le client peut récupérer la PO tout moment par la suite (pour mettre à jour / modifier il). Le PO est devenu un élément d’information qui est partagée entre le client et le serveur. L’information partagée (PO) est donné une adresse (URL) par le serveur et est exposé comme un service Web.

URL logiques par rapport URL physiques
Une ressource est une entité conceptuelle. Une représentation est une manifestation concrète de la ressource. Cette URL:

http://www.parts-depot.com/parts/00345

est une URL logique, pas une URL physique. Ainsi, il n’a pas besoin d’être, par exemple, une page HTML statique pour chaque partie. En fait, s’il y avait un million de parties alors un million de pages HTML statiques ne seraient pas un design très attrayant.

[Détail de mise en œuvre: Parts Depot pourrait mettre en œuvre le service qui reçoit des données détaillées sur une partie particulière en utilisant un servlet Java qui analyse la chaîne après le nom d’hôte, utilise le numéro de pièce pour interroger la base de données de pièces, de formuler les résultats de requête en XML, et puis retourner le XML en tant que charge utile de la réponse HTTP.]

En URL de style ne devrait pas révéler la technique de mise en œuvre utilisée. Vous devez être libre de changer la mise en œuvre sans affecter les clients ou d’avoir des URL trompeuses.

Web Services REST Caractéristiques
Voici les caractéristiques de REST:

  • Client-Serveur: une interaction de type base de pull-: composants consommant tirer représentations.
  • Stateless: chaque demande du client au serveur doit contenir toutes les informations nécessaires pour comprendre la demande, et ne peut pas profiter de tout contexte stocké sur le serveur.
  • Cache: pour améliorer les réponses de l’efficacité du réseau doit être capable d’être étiqueté comme cacheable ou non mis en cache.
  • Interface uniforme: toutes les ressources sont accessibles par une interface générique (par exemple, HTTP GET, POST, PUT, DELETE).
  • Ressources nommées – le système est composé de ressources qui sont nommés à l’aide d’une URL.
  • Représentations de ressources interconnectées – les représentations des ressources sont interconnectés via des URL, ce qui permet à un client de passer d’un état ​​à un autre.
  • Composants en couches – intermédiaires, tels que les serveurs proxy, serveurs de cache, passerelles, etc, peuvent être insérés entre les clients et les ressources pour soutenir la performance, la sécurité, etc

Principes de REST Web Design Service
1. La clé pour créer des services Web dans un réseau de REST (le Web) est d’identifier toutes les entités conceptuelles que vous souhaitez exposer en tant que services. Ci-dessus, nous avons vu quelques exemples de ressources: Liste des pièces, données de pièces détaillées, des bons de commande.

2. Créer une URL pour chaque ressource. Les ressources doivent être des noms, pas des verbes. Par exemple, ne pas utiliser ce:

http://www.parts-depot.com/parts/getPart?id=00345

Notez le verbe, getPart. Au lieu de cela, utilisez un nom: 

http://www.parts-depot.com/parts/00345

3. Classez vos ressources en fonction de si les clients ne peuvent tout simplement recevoir une représentation de la ressource, ou si les clients peuvent modifier (ajouter) la ressource. Pour le premier, faire de ces ressources accessibles via une requête HTTP GET. Pour la suite, rendre ces ressources accessibles via HTTP POST, PUT et / ou DELETE.

4. Toutes les ressources accessibles via HTTP GET doivent être l’effet secondaire libre. Autrement dit, la ressource doit simplement retourner une représentation de la ressource. Invoquant la ressource ne doit pas conduire à modifier la ressource.

5. Aucun homme / femme est une île. De même, aucune représentation devrait être une île. En d’autres termes, mettre des liens hypertextes dans les représentations de ressources pour permettre aux clients de forer vers le bas pour plus d’informations et / ou pour obtenir des informations connexes.

6. Conception de révéler des données progressivement. Ne pas tout dévoiler dans un document de réponse unique. Fournir des hyperliens pour obtenir plus de détails.

7. Spécifiez le format de données de réponse à l’aide d’un schéma (DTD, Schema W3C, RelaxNG, ou Schematron). Pour les services qui nécessitent un POST ou qui lui sont posées, aussi fournir un schéma pour spécifier le format de la réponse.

8. Décrivez comment vos services doivent être invoquée en utilisant soit un document WSDL, ou tout simplement un document HTML.
résumé
Cet article décrit REST comme un style architectural. En fait, c’est le style architectural du Web. REST décrit ce qui rend le Web fonctionne bien. Adhérant aux principes de REST rendra vos services fonctionnent bien dans le contexte du Web.

Dans un prochain article je vais écrire sur l’évolution du Web en utilisant les principes de REST.

Accusé
Merci à Robert Leftwich et Philip Eskelin pour leurs commentaires très utiles dans la création de ce document.

 

références

[1] ~ http://www.ics.uci.edu/ mise en service / pubs / dissertation / top.htm

Comments are closed.