SOAP Web Services require sending messages in XML. The format normally used is that specified by the SOAP XML Schema, which is very flexible and able to handle any complex combination of parameters and return values for invoking an operation. The messages consist mainly of an envelope and a body. The envelope describes the message and its encoding, and the body holds the details of the message regarding the request or response.
For an example, please check this basic SOAP tutorial.
As you can see, messages in SOAP include information about which operation is being invoked. On the other hand, messages in RESTful web services do not need to include such information as it is implied in the HTTP protocol method being invoked (e.g. GET -> Get, PUT -> Create, POST -> Update, DELETE -> Delete) Due to that, messages in RESTful web services do not need to follow a particular format either, and thus usually have a much ligher format than SOAP.
Since SOAP messages follow a standard, they do not need to be manually coded as there are tools that can generate them and consume them automatically, based on existing interfaces in the language of choice. On the other hand, RESTful messages are usually proprietary, requiring extra effort on behalf of the programmers to design, generate and consume. That said, there have been efforts to standardize RESTful messages in particular domains and provide automatic generators and consumers. The best example for that is the Ruby on Rails RESTful web services generated using the Rails scaffold_service command.
The benefits one gets from using SOAP messages are:
- Flexibility to handle any method names, combination parameters, and return values
- Preserving continuity of domain models across the wire, by being able to pretend you are working with a local service
- Availability of Web Service generation/consumption tools due to having a standard
The benefits in having a less-rigid message format as usually used in RESTful web services:
- Easier to read messages when troubleshooting problems
- Less data overhead in the message format, improving performance over the wire dramatically, especially when sending and receiving many small messages.
- Breaking the domain model by switching to simple CRUD operations when data traverses wires reminds developers of the important concerns related to network communication, such as reliability and performance.
If your integration use-cases are usually simple and not numerous, you can save yourself from dealing with a lot of complexity by employing RESTful web services instead of SOAP Web Services (or a hybrid approach), gaining generally better performance, scalability, reliability, and popularity for your web services. One of the best examples is the Amazon S3 web service, which due to RESTfulness has a very wide popularity over the web today.