REST vs SOAP : quelles différences ?
Permettant tous deux de développer des API, les technologies REST (pour REpresentational State Transfer) et SOAP (Simple Object Access Protocol) sont techniquement différentes. La première est une architecture alors que la seconde est un protocole. La différence majeure entre les deux éléments réside dans le degré de liaison entre le client et le serveur. Un client développé avec le protocole SOAP ressemble à un logiciel d'ordinateur, car il est étroitement lié au serveur. Si une modification est effectuée d'un côté ou de l'autre, l'ensemble peut ne plus fonctionner. Il faut effectuer des mises à jour du client s'il y a des changements sur le serveur et vice-versa.
Un client de type REST en revanche utilise un protocole et des méthodes standardisées. Il y a par conséquent beaucoup moins de couplage entre le client et le serveur : un client peut utiliser un service de type REST sans aucune connaissance de l'API. A l'inverse, un client SOAP doit tout savoir des éléments qu'il va utiliser pendant son interaction avec le serveur, sinon cela ne fonctionnera pas.
A la différence de SOAP, REST utilise un protocole et des méthodes standardisées
Par ailleurs, REST est indépendant d'un protocole. On peut utiliser aussi bien le protocole HTTP que FTP, tant qu'il s'agit d'un protocole possédant un schéma standard pour une URI (Uniform Resource Identifier). REST est aussi standard que les éléments que vous utilisez pour développer votre application. Si vous utilisez le protocole HTTP, alors certaines parties comme l'authentification ou encore la sécurité seront standardisées, car elles le sont avec HTTP.
Si vous souhaitez développer une application respectant pleinement REST (on appelle cela une application RESTful), il faut savoir que votre client ne doit connaître que le point d'entrée de l'API ainsi que le type de données qui est attendu. Les API fournissant une documentation complète avec les schémas d'URL ne sont donc pas RESTful, car, en donnant cette documentation, ils informent le client sur les possibilités de l'API à un moment particulier de son existence. Une modification de l'API doit donc être documentée sinon cela peut conduire à des dysfonctionnements.