Differences between REST and SOAP
Have you ever heard the sentences "REST is so much better than SOAP", since you're using SOAP and not REST. "It is so much effort to change the interface". Then you're most probably a developer for an enterprise web server. Its right, changing an interface is always a big effort, but having a proper interface description should never be considered as a pain. So from a SOAP perspective it's all about interfaces, REST is about resources. Mixing this up you could also use OAuth for authentication.
Let's Start with SOAP. SOAP is a protocol for remote procedure calls (RPC) such that two systems can exchange data. It is build on top of http and uses xml for data representation. The interface is modeled in the web service description language. A proper description of the interface is probably the most important feature of SOAP. Sadly this is the point where I hear the most criticism of SOAP. It's not working or it's so difficult to change the interface. Sometime it's only that the responsible person has no deeper insight into SOAP services, sometimes it's only some weird restrictions and extensions from your client.
REST is the new cool fancy hip paradigm used by Google, Amazon and others, that finally make use of all those forgotten http commands like put and delete. It's able to handle JSON that isn't that verbose like XML but almost as powerful. But REST is different, it's meant to address resources, not functionality. It is designed as a clarification how a good web should work. It is self describing and explorable. One resource like a HTML site shows you some new resources that you can 'GET'. Even the claim that it should be stateless is funny since most service calls uses database with is clearly not stateless and therefore does not scale infinitely. But this is okay, it's only not allowed to cache, calling the database is only a request for additional information.
Of course no webdesigner would ever consider to use SOAP as a backend interface. Only by thinking of how difficult it is to handle xml in JavaScript. But also never underestimate a clearly defined interface in a B2B application.
Hopefully you don't have to decide between using the right technology wrong and using the wrong technology.
Let's Start with SOAP. SOAP is a protocol for remote procedure calls (RPC) such that two systems can exchange data. It is build on top of http and uses xml for data representation. The interface is modeled in the web service description language. A proper description of the interface is probably the most important feature of SOAP. Sadly this is the point where I hear the most criticism of SOAP. It's not working or it's so difficult to change the interface. Sometime it's only that the responsible person has no deeper insight into SOAP services, sometimes it's only some weird restrictions and extensions from your client.
REST is the new cool fancy hip paradigm used by Google, Amazon and others, that finally make use of all those forgotten http commands like put and delete. It's able to handle JSON that isn't that verbose like XML but almost as powerful. But REST is different, it's meant to address resources, not functionality. It is designed as a clarification how a good web should work. It is self describing and explorable. One resource like a HTML site shows you some new resources that you can 'GET'. Even the claim that it should be stateless is funny since most service calls uses database with is clearly not stateless and therefore does not scale infinitely. But this is okay, it's only not allowed to cache, calling the database is only a request for additional information.
Of course no webdesigner would ever consider to use SOAP as a backend interface. Only by thinking of how difficult it is to handle xml in JavaScript. But also never underestimate a clearly defined interface in a B2B application.
Hopefully you don't have to decide between using the right technology wrong and using the wrong technology.
| SOAP | REST | |
|---|---|---|
| Type | Protocol | Paradigm |
| Used for | Defining Interfaces | Addressing Resources |
| Payload language | XML | Not defined, mostly JSON |
| Useful for | communication between webserver | communication between browser and webserver |