REST ou SOAP : quelle technologie profite le plus aux applications mobiles ?
En matière d'applications mobiles, au moment de choisir entre REST et SOAP, il faut garder à l'esprit qu'il existe deux modèles dominants : les applications natives et incorporées.
Quel est le principal avantage de l'architecture REST sur le protocole SOAP dans les applications mobiles ? Si vous avez déjà discuté avec un authentique « pro-REST », ou ne serait-ce que lu son point de vue, vous savez probablement que REST (Representational State Transfer) constitue l'architecture du Web. Et il y a pas mal de vrai là-dedans...
C'est incontestable : l'architecture REST est particulièrement adaptée aux interactions par le biais de navigateurs. Les navigateurs et les moteurs qui les sous-tendent sont développés pour activer les liens présents dans les contenus qu'ils traitent, et pour fournir un ensemble de gestionnaires, ou « handlers », destinés aux différents types de réponses possibles. En matière de navigateurs, le langage de programmation dominant est JavaScript. Et, il faut bien le reconnaître, tenter de programmer un client SOAP (Simple Object Access Protocol) en JavaScript n'est pas une partie de plaisir. Nous avons même renoncé à utiliser le langage XML (eXtensible Markup Language) au profit de JSON (JavaScript Object Notation).
Mais pourquoi parler des navigateurs Web alors que la question porte sur les applications mobiles ? Je commence par le navigateur Web pour deux raisons.
D'abord, il existe bel et bien deux modèles dominants pour les applications Web mobiles : natif et incorporé. Les applications natives sont développées de A à Z au moyen des langages, des bibliothèques natives et des kits d'outils du système d'exploitation mobile concerné. Par exemple, pour les appareils iOS, il s'agit d'Objective C et des bibliothèques et kits d'outils fournis par Apple pour iOS. La logique de présentation est installée sur l'appareil en même temps que l'application.
En revanche, les applications Web mobiles incorporées se contentent d'exploiter un composant natif qui « incorpore » un navigateur Web. Ce composant agit également en tant que passerelle entre le navigateur et les fonctionnalités de l'appareil, comme en cas d'interaction avec sa galerie de photos. Ici, la majeure partie de la logique de présentation n'est pas installée en même temps que l'application, mais téléchargée via le Web lorsque l'application s'exécute. Dans ce type de fonctionnement, nous revenons à une approche Web typique en JavaScript ; et le recours à SOAP n'est pas envisageable.
Mais quid des applications natives ? Pourquoi ne pas utiliser SOAP dans leur cas ? Concernant Android et iOS, des bibliothèques tierces facilitent l'appel de services Web SOAP, mais il n'existe aucune prise en charge native « prête à l'emploi ». Cela n'a rien de très surprenant dans le cas d'iOS : Objective-C a pour origine la programmation bureautique du Mac, et SOAP l'intégration d'entreprise. C'est un peu plus étonnant, en revanche, dans le cas d'Android, sachant que Java a été le premier langage pris en charge pour le développement d'applications.
En réalité, tout cela se résume à une question d'ubiquité et de simplicité. Tout d'abord, si les plateformes natives n'offrent aucun support direct de SOAP, elles prennent en charge les langages HTTP et XML. Il y a donc bien ubiquité. Côté simplicité, XML fait certainement mieux que SOAP. Et dans le cas d'applications Web mobiles incorporées, JavaScript fait mieux que XML.
En réalité, tout cela se résume à une question d'ubiquité et de simplicité.
Toutefois, REST ne se limite pas à JSON ou XML, mais touche tout type de support que le navigateur ou la plateforme peut gérer en natif. Si je peux récupérer un flux d'octets et simplement le transmettre aux fonctionnalités du navigateur ou d'un composant de présentation natif, plutôt que de faire transiter ces données par un dispositif de type enveloppe SOAP, les choses sont non seulement plus simples, mais elles sollicitent également moins le processeur, ce qui signifie davantage d'autonomie pour la batterie de l'utilisateur.
