This is an article about how to call .NET SOAP Webservices from an HTML page. However it should be useful for anyone wanting to call any webservice from a webpage, as it outlines the technical considerations and plumbing you need to keep in mind.
There are four considerations to bear in mind
1. The type of data sent to the server and the type of data returned from the server. Consider the following,
The type of data sent to the server is XML. The type of data retrieved from the server is JSON. However, you will often want to accept / retrieve the other. Keep this in mind for the next step.
As well, if you receive XML or JSON, you will often need to deserialize into a string. Either use JavaScript's XMLSerializer or use JSON.parse to get the data you want in string format. The same goes for data you send to the server (it must be JSON.stringify or serialized into XML before sending it, not just a JavaScript string)
2. The jQuery AJAX call itself. For example consider the following
Match the content type parameter to the required input data, either 'application/xml' or 'application/json'. Note that trying 'application/soap+xml' or other unexpected content types will generate a server error in response.
3. CORS. If the HTML page is hosted on a different domain than the webservice itself (might be true in Enterprise where the webservice is on a different server than the web server) then CORS applies. Note that when using jQuery with methods other than GET, jQuery will send a preflight OPTIONS request so the server will need to accept OPTIONS and GET and POST, in addition to the appropriate CORS headers on the server side response and the HTML tags. So if you cannot control the server-side headers on your webserver, you will need a different application architecture. Perhaps call the webservice from the backend C# instead of trying to call it from the HTML.
4. The SOAP envelope. You've got three choices here
- Retrieve the SOAP string from some external source, like a database or a text file. Every time the webservices are updated, you will have to update the external source.
- Construct the SOAP envelope yourself with a JavaScript client. This is the approach I do not recommend, since parsing a WSDL and associated XSDs is not trivial.
- Have a project like Apache CXF generate the SOAP client for you. This defeats the purpose of this article, since Apache CXF is a JavaScript client already. But this is an option, especially for Java backends or Enterprise.
In order to avoid these issues, have the webservice allow JSON if possible. If the architecture of the software is to allow access to the webservices from the client side (HTML pages) then the webservice should speak the lingua franca of the web (JSON) or else there's no point even exposing the webservice to the client side.
Make sure to know what type of binding the server allows, either wsHTTPBinding or basicHTTPBinding. This means a different SOAP Envelope. You may have to strip the envelope from the XML before sending it, if WCF expects only the inner request XML and not the SOAP envelope.
I hope this helps someone build their dream application. Thanks.
i had no idea it would work this way. i spent hours using the basics but now that i have read your post i feel my eyes to be finally opened
ReplyDeleteSometimes a solution is on the surface, and you are looking somewhere deep. Thank you for your advice and examples of the tasks that you describe.
ReplyDelete