Showing results for 
Search instead for 
Did you mean: 


I have read articles about the differences between SOAP and REST as a web service communication protocol, but I think that the biggest advantages for REST over SOAP are:

  1. REST is more dynamic, no need to create and update UDDI(Universal Description, Discovery, and Integration).

  2. REST is not restricted to only XML format. RESTful web services can send plain text/JSON/XML.

But SOAP is more standardized (E.g.: security).

So, am I correct in these points?


SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.

Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change, but it's easier to ascertain if the contract is being followed.

A REST client is more like a browser. It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. If done right, there's less coupling, and changes can be dealt with more gracefully. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. In SOAP, the client needs previous knowledge on everything it will be using, or it won't even begin the interaction. Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being JavaScript code used to drive the interaction with another service on the client-side.

I think these are the crucial points to understand what REST is about, and how it differs from SOAP

SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are both ways to pass messages between computing processes over the Internet.

SOAP, which has been around for much longer, uses an XML payload to pass the messages. That XML payload can be delivered over the web (HTTP), but it can also be delivered via different protocols, such as those for email (SMTP).

So, think about it like a package you're sending to your buddy. They need to act on the instructions in your package. With SOAP, you have to construct those instructions in a rigid, detailed manner as an XML file and put it in a box and send it to your buddy. He then has to open the box, decipher those instructions, and act on them.

REST is much lighter weight. With REST, the messages are usually encoded as part of the URL, so a payload isn't absolutely necessary (though possible, of course). So a lot can be done with the usual HTTP methods of GET, POST, PUT, and DELETE. You can only use HTTP, though.

Think of REST this way: instead of having to create a bunch of instructions and package them up in a box, you just include the instructions as another line in the address (the URL) on the outside of the box itself. When you send that to your buddy, it's less work for them because they don't have to deal with opening the box, figuring out what's inside, and deciphering all those instructions. echatrandom

That's way oversimplifying, but it's a start.