Les développeurs Web ont de nos jours un vaste panel de technologies à leur service. Du simple accès à la base de données, en passant par l'assemblage de middlewares existants, jusqu'à une pléthore de framework côté client, ces produits et outils donnent aux développeurs Web la possibilité de créer de meilleures applications web plus rapidement.
Disposer de multiples solutions logiciels est un challenge, choisir une approche spécifique pour certaines parties de l'application web en est un également. En outre, les développeurs web doivent également tenir compte de standards et approches qui semblent changer tous les jours ou presque.
Prenons l'exemple des deux approches pour s'interfacer avec des services web, SOAP (Simple Object Access Protocol) et REST (Representational State Transfer). Les deux approches fonctionnent et présentent des avantages et inconvénients. Il appartient au développeur de décider quelle approche sera préférable pour chaque cas particulier.
La plupart des développeurs ont été exposés à l'approche REST, qui utilise une URI (Uniform Resource Identifier) standard appelant un service web comme https://www.mycompany.com/programme/méthode?Paramètres=xx. Cette approche est très simple à comprendre et peut être mise en oeuvre sur n'importe quel client ou serveur supportant HTTP/HTTPS. Cette commande s'exécute via la méthode HTTP GET. Ainsi, les développeurs qui utilisent cette approche citent la facilité de développement, l'utilisation de l'infrastructure Web existante et le faible coût de formation comme des avantages clés de ce style.
Cependant SOAP, le grand-père de toutes les interfaces de services Web, ne va pas disparaître de sitôt. En effet, SOAP 1.2 a comblé certaines faiblesses perçues de cette technologie, poussant son adoption et sa facilité d'utilisation à de nouveaux niveaux. Il convient également de noter que SOAP n'est plus l'acronyme de Simple Object Access Protocol d'après la spécification 1.2 de l'organisation W3C, il est maintenant juste le nom de la spécification.
Il faut garder à l'esprit que l'utilisation de SOAP 1.2 a un coût supplémentaire par rapport à l'approche REST. Cet investissement a malgré tout des avantages. Tout d'abord, SOAP s'appuie sur le langage XML (Extensible Markup Language) de trois façons; l'enveloppe - qui définit ce qui est dans le message et comment le traiter, une grammaire pour les types de données et enfin, l'organisation des requêtes/réponses. L'enveloppe SOAP XML contenant la requête est envoyée via le protocole (HTTP/HTTPS), un RPC (Remote Procedure Call) est exécuté et l'enveloppe SOAP contenant la réponse est renvoyée dans un document au format XML.
Il est important de noter que l'un des avantages de SOAP est l'utilisation d'une couche «générique» de transport. Alors que REST n'emploie que le protocole HTTP/HTTPS, SOAP peut utiliser presque n’importe quelle couche de transport pour envoyer la demande, par exemple SMTP (Simple Mail Transfer Protocol) ou bien JMS (Java Messaging Service). Cependant, un inconvénient perçu est l'utilisation de XML du fait de sa verbosité et du temps qu'il faut pour son analyse syntaxique.
Cependant, la bonne nouvelle pour les développeurs web, c'est que les deux technologies sont tout à fait viables dans le marché actuel. REST et SOAP peuvent résoudre un grand nombre de problèmes et de défis web, et dans de nombreux cas, chacun d'eux peut être adapté au besoin des développeurs.
L'histoire secrète, c'est que les deux technologies peuvent être combinées. REST est très facile à comprendre et est très accessible, mais il est non standardisé et est plus considéré comme une approche architecturale. En comparaison, SOAP est un standard de l'industrie avec un protocole bien défini et un ensemble de règles bien établies à mettre en œuvre et il a été utilisé dans des systèmes à la fois grands et petits.
En conséquence, cela signifie que les besoins pour lesquels REST fonctionne vraiment bien sont les suivantes:
- Bande passante et ressources limitées: rappelez-vous que la structure de retour peut être de n'importe quel format (au choix du développeur). De plus, n'importe quel navigateur peut être utilisé puisque l'approche REST utilise les méthodes standards GET, PUT, POST et DELETE. Encore une fois, n'oubliez pas que REST peut également utiliser l'objet XMLHttpRequest que la plupart des navigateurs modernes prennent en charge aujourd'hui, ce qui ajoute un bonus supplémentaire d'AJAX.
- Opérations sans état (stateless): si une opération doit se poursuivre, alors REST n'est pas la meilleure approche et SOAP peut mieux convenir. Toutefois, si vous avez juste besoin d'opération sans état CRUD (Create, Read, Update et Delete), alors REST est la solution.
- La mise en cache: si les informations peuvent être mises en cache l'absence d'état de l'approche REST est parfaite.
Les trois cas ci-dessus couvrent un grand nombre de besoins. Pourquoi donc devriez-vous même envisager SOAP ? Encore une fois, SOAP est assez mature, bien défini et vient avec une spécification complète. L'approche REST est simplement ça: une approche et il est grand ouvert pour le développement. Par conséquent, si vous êtes dans les cas suivants, SOAP est une excellente solution:
- Le traitement et l'invocation asynchrone: si votre application a besoin d'un niveau de fiabilité et de sécurité garanti, alors SOAP 1.2 offre des normes supplémentaires pour assurer cela, des spécifications comme WSRM - WS-Reliable Messaging par exemple.
- Contrats formels: si les deux parties (fournisseur et consommateur) se mettent d'accord sur le format d'échange alors SOAP 1.2 donne un cadre strict pour ce type d'interaction.
- Opérations avec état: si l'application a besoin d'informations contextuelles et de la gestion d'état conversationnel alors SOAP 1.2 a la spécification supplémentaire dans la structure WS* pour soutenir ces besoins (sécurité, transactions, coordination, etc.). En comparaison, l'approche REST forcerait les développeurs à créer une plomberie personnalisée.
Comme démontré ci-dessus, chaque approche technologique a ses usages. Ils ont tous deux des problématiques sous-jacentes liées à la sécurité, les couches de transport, etc., mais ils peuvent aussi bien l'un que l'autre faire l'affaire et dans de nombreux cas, ils apportent chacun quelque chose au Web. Donc, pour cette décision, la meilleure règle est celle de la flexibilité, parce que peu importe le problème, les développeurs Web ont d'excellentes solutions en utilisant l'un de ces protocoles.
À propos de l'auteur
Mike Rozlog est le senior directeur des produits chez Embarcadero Technologies. Son rôle est de s'assurer que les produits créés par Embarcadero pour les développeurs répondent aux attentes de ces derniers. Une grande partie de son temps est consacrée à l'examen et à l’explication des aspects techniques et commerciaux des produits et services d'Embarcadero aux analystes et autres publics à travers le monde. Mike était auparavant chez CodeGear, un groupe développant des outils pour les développeurs acquis par Embarcadero en 2008. Auparavant, il a travaillé plus de huit ans pour Borland dans différents postes, y compris un rôle de premier plan en tant qu'architecte technique en chef. Auteur réputé, puisque Mike a publié de nombreux livres. Sa dernière collaboration est Mastering JBuilder chez John Wiley & Sons, Inc.