Restful web services support only four methods –
GET, PUT, POST and DELETE.
This is in contrast to SOAP, where there is no standard
specification of methods supported.
Every SOAP service defines its own supported methods
(along with their signature) by WSDL.
Accordingly, it can be argued that SOAP enforces a
stricter type compatibility whereas REST does not dictate any such
SOAP services talk through XML while REST defines no
REST request-response can be pretty much anything like
XML, JSON or any format developed by individual developers or
company. In this way, it gives more flexibility to the developers and
does not force them to use only XML.
Note that SOAP does not rule out non-XML content straight-away.
The non-XML content can be transferred through XML by encoding it using base-64
and then wrapping that into the XML but then the resulting XML is almost always bulkier
than the original non-XML content and thus the purpose of SOAP is somewhat defeated.
In practice, use SOAP when the API you are exposing as web service is very well defined.
And you are ready to take the trouble of creating and distributing WSDL for your web-service.
Benefit of this effort is that API clients are very clear on the format of the API.
But if the web service is intended to be used internally and that too among a few parties only, then go for REST
as REST can be developed much faster and any changes to the API request-response can be communicate easily to
the smaller set of audience.
Some more differences between REST and SOAP
1) SOAP responses can't be cached because SOAP uses the HTTP POST verb, which is considered unsafe.
REST allows the use of all four verbs - GET, PUT, POST and DELETE. GET requests among these can be cached.
2) WS-Security is an extension to SOAP which specifies how a SOAP message can be sent more securely.
It specifies how SOAP messages can be signed, encrypted and attached with tokens of sender's identity.
Thus, SOAP by itself is not more secure than REST, but the usage of WS-Security makes it more secure.
To make REST secure, SSL encryption can be used (https instead of http). SSL encryption over https can be used to make SOAP connections secure too.
So, in summary, SOAP is not more secure than REST by itself. If https suffices your security needs, then REST
over https is just as secures as SOAP over https. If the medium of transmission is other than https, then SOAP with WS-Security is more secure.
Like WS-Secure, some other WS-* tools are WS-Trust, WS-SecureConversation and WS-Federation.
3) SOAP supports transactions by another tool called WS-Atomic Transactions.
REST has no support for doing this and if its required, than the developer should build those themselves into their system.
However, transactions are not required so frequently and it makes sense to develop a
system locally if a very few percentage of your web services use transactions.
Finally, in summary, there is not clear winner among SOAP and REST.
While SOAP provides a full blown set of features by using WS-* toolkits, REST remains very simple and provides no such tools.
If the requirements demand a heavy use of transactions and the messages are intended to be sent securely across non-https channels,
then SOAP is the answer, else REST may be easier and faster to use.
Got a thought to share or found a bug in the code? We'd love to hear from you: