Sur Interwingly, on a essayé de réconcilier le style architectural « REST » et les technologies d’appel à des procédures distantes (RPC). Les arguments d’une possible réconciliation sont les suivants :

• croire que faire du HTTP GET suffit pour faire du REST, c’est une erreur
• croire qu’avec SOAP, on ne peut faire que du RPC, c’est une erreur
• si vous êtes un RESTafarien, vous devriez vous demander pourquoi la plupart des systèmes de bases de données relationnelles modernes incluent un mécanisme de procédure stockée (l’équivalent du RPC)
• tout serait question d’enveloppe : qu’est-ce que je mets dessus (la référence de ce que j’invoque) ? qu’est-ce que je mets dedans (les paramètres…?)
• si vous êtes dans le cas d’une application pour laquelle il faut privilégier l’évolutivité (« scalabilité ») et pour laquelle les données sont davantage en lecture qu’en écriture (tiens, ça fait penser aux annuaires LDAP, ça), alors l’approche REST s’impose
• si vous êtes dans le cas d’une application pour laquelle il convient de gérer des écritures/mises à jour non atomiques, alors c’est peut-être dans SOAP que réside votre solution
• un point fort de REST par rapport à SOAP + WSDL, c’est la facilité avec laquelle on peut lier des ressources entre elles
• un point fort de SOAP par rapport à REST serait un gain de performance similaire à celui-ci qui résulte de l’emploi de procédures stockées dans le cas d’une base relationnelle