SOAP vs REST: The war between simplicity and standards
SOA is, at its core, a design and development methodology. It embraces reuse through decomposition of business processes and functions into core services. It enables agility by wrapping services ...
Published Dec 05, 2008
Version 1.0
Lori_MacVittie
Employee
EmployeeLori_MacVittieEmployee
Employee
Lori_MacVittieEmployee
Employee@David,
They are, agreed, and they are also used by SOAP.
REST is standard-less in terms of integration and implementation. There's no standard that describes even the format of data being exchanged via REST, unlike SOAP. SOAP requires XML, REST is ambivalent - you can do what you want.
When you interact with a SOAP service you know what to expect - it's always the same: WSDL, XML, SOAP envelopes/headers. When you interact with a REST service it's another story. POST? GET? Query string? Data formatted in ... what? JSON? XML? TEXT?
The standards wrapped around SOAP make integration and reuse much simpler than REST, even though the actual development of REST is much easier.
I'm not against REST at all, to be honest. Love it, use it often, think it's great. Same with SOAP. I'm just against the argument that REST is "simpler" and "less costly" than SOAP because it really isn't. The cost and complexity with REST is just found in different places than it is with SOAP.