Remplacer le format SOAP par les services web REST

Le format SOAP (Simple Object Access Protocol) pour appeler un service web, est puissant et très répandu, mais ce n’est pas le seul moyen à votre disposition. On lui a certes beaucoup reproché d’être trop compliqué et lourdaud. De nombreux experts le jugent parfois même trop puissant et suggèrent plutôt REST aux développeurs.

HTTP est peut-être le protocole de transfert de données le plus largement utilisé. Il permet de transférer des données d’un serveur web (comme Apache, IIS, Tomcat, ou webSphere) à un navigateur web du genre Internet Explorer, Firefox, ou Chrome. Dans les années 90, étudiant à l’UC Irvine, Roy Fielding a été le coauteur du protocole HTTP. Dans sa thèse, Fielding a décrit l’architecture avec laquelle il était prévu d’utiliser HTTP, sous le nom de REST. Pour ma part, je n’aime pas l’appellation « Representational State Transfer », mais j’aime bien l’acronyme REST ! Dans le jargon des services web, on appelle service web RESTful un service qui est mis en oeuvre à l’aide de l’architecture REST.

Cet article explique comment écrire un programme RPG qui se connecte au service web d’autrui afin d’utiliser ce service. Ce genre de programme est logiquement appelé « consommateur de service web ». Dans un futur article, je décrirai l’écriture côté serveur.

REST n’est pas un standard, et ne concerne pas vraiment les services web. C’est un simple style architectural qui assimile les choses à des ressources. La ressource est un terme générique qui désigne une chose. Les ressources sont identifiées par un identificateur de ressource uniforme (uniform resource identifier, URI), dont voici un exemple :

http://example.com/order/54321

Déjà vu ? Bien sûr : sur la barre de votre navigateur web. L’URI est la tuyauterie de la Toile ou World Wide web. Elle pointe vers une commande numérotée 54321 qui se trouve sur un serveur nommé example.com et est accessible par le protocole HTTP. Cette commande est une ressource particulière sur laquelle vous pouvez opérer. Le web est un gigantesque exemple de l’architecture REST.

En substance, REST c’est cela. Vous allez à un URI particulier et les données qu’il contient disent à un programme (tournant sur un serveur HTTP) quelles données vous voulez extraire. Ce pourrait être un document statique, ou bien le contenu de l’URI pourrait servir de paramètres à un programme tournant sur le serveur. D’une façon ou d’une autre, le serveur sait ce que vous voulez et il renvoie les données. L’architecture REST permet de renvoyer toutes sortes de données, mais dans le monde des services web, il s’agit généralement d’un simple document XML ou d’un document JSON (JavaScript Object Notation).

Les noms de RESTful vs. les verbes de SOAP

La philosophie de REST consiste toujours à identifier une chose via l’URI. Disons que votre URI pointe vers un nom, une chose sur laquelle il faut agir. À l’inverse, SOAP se concentre toujours sur les verbes. Dans SOAP, un URI tend à identifier une action à effectuer, comme getWeather, createOrder, ou changeReservations. REST tend à utiliser un URI comme un nom, comme la météo d’une certaine ville, une commande dans une application de gestion, ou une réservation. Il utilise ensuite les méthodes HTTP comme des verbes pour identifier ce qui est fait. Il y a beaucoup de méthodes HTTP, mais les principales sont GET, POST, PUT, et DELETE. Vous pouvez les considérer comme analogues aux opcodes CHAIN, WRITE, UPDATE, et DELETE en RPG. Elles fonctionnent toujours conjointement à un URI, donc vous pouvez considérer que l’URI est analogue à un format d’enregistrements à lire ou à mettre à jour. Quand vous tapez un URI dans la boîte de localisation de votre navigateur, il utilise toujours la méthode GET HTTP. Donc, quand vous tapez un URI dans votre navigateur, vous lui demandez de lire un document. Voici les significations des autres méthodes de base:

• GET = extraire de l’information. Si l’URI pointe vers météo, GET extraira la météo.
• POST = créer de la nouvelle information. Si l’URL pointe vers la météo, POST définira la prévision pour une ville donnée. S’il pointe vers une commande, il pourrait servir à créer une nouvelle commande.
• PUT = mettre à jour ou changer l’information. Théoriquement, cela pourrait servir à modifier une chose existante, comme mettre à jour la quantité d’une commande ou changer la date d’une réservation.
• DELETE = supprimer l’information. Annuler une commande ou une réservation.

Cela, c’est la théorie ou la philosophie. En réalité, la plupart des serveurs HTTP n’appliquent pas les méthodes PUT et DELETE. Donc GET est utilisé pour extraire l’information, et POST sert à tout le reste. POST est souvent flanqué d’une variable qui précise si les données sont créées, mises à jour ou supprimées.

Je pense qu’en matière de programmation, des exemples valent mieux que des descriptions. Et comme j’ai vraiment envie de vous montrer du code RPG, je termine ici ma description. Si vous voulez plus de détails sur REST, je vous recommande l’article de Ryan Tomayko « How I Explained REST to My Wife » (tomayko.com/writings/rest-to-my-wife).