Why is it not a good idea to use SOAP for communicating with the front end? For example, a web browser using JavaScript.
views:
422answers:
4Because SOAP reinvents a lot of the HTTP wheel in its quest for protocol-independence. What's the point if you know you're going to serve the response over HTTP anyway (since your client is a web browser)?
UPDATE: I second gizmo's (implied) suggestion of JSON.
- Because it's bloated
- Because JSON is natively understandable by the JavaScript
- Because XML isn't fast to manipulate with JavaScript.
It could be done. Just remember that SOAP is not the fastest way to exchange information as there is a big overhead (big XMLs have to be sent back and forth) - that's probably why you don't see it used that often
If the web browser is your only client then I would have to agree that SOAP is overkill.
However, if you are going to have multiple types of front end clients on running on different platforms then SOAP may be appropriate. The nice part about SOAP is that there are a lot of tools out there that will generate code for you to handle sending, receiving, and parsing of SOAP based on the WSDL file.
For example, if you wanted to develop a C++ front end client then all you need is the WSDL file and Microsoft's tools will generate all the C++ code to generate the SOAP request based on a data structure, send the request, receive the response, and parse the response into a return data structure.
There are tools to do this both on the client and server side.