Here's what you need to try out this dynamic
script tag request:
To create my class, I distilled a lot of existing information, and then adapted it to fit no. 2 above. Until recently, finding a web service that returns JSON and lets you specify a callback function was, well, darn near impossible unless you wrote one yourself. Fortunately, Yahoo recently has offered the option on many of their REST-ish web services. Notably, their many search web services, and their geocoding, map image, and traffic web services, now can return JSON wrapped in a callback function.
Compared to using the
XMLHttpRequest object and a proxy, this stuff is easy. The
JSONscriptRequest class does the messy work of creating the
script tag dynamically which makes the actual web service request. For a quick example, I'll do some geocoding, turning a zip code -- in this case zip code 94107 -- into a latitude/longitude pair, using Yahoo's Geocoding Web Service.
Running this application makes a request to Yahoo's Geocode web service and yields the following alert box which displays the latitude and longitude of the zip code 94107.
Figure 1. Alert box
The web service request -- the
req variable in the script above -- specifies that the web service should return JSON-encoded data (
output=json) and that the data should be wrapped in a callback function named
callback=getGeo). You can cut and paste that URL into your browser to see the output of the web service. The output looks like this (or click here):
script tag). For comparison, look at the XML version of this call here.
buildScriptTag method of the
JSONscriptRequest object builds a
script tag that looks like this:
To actually execute the web service request, the
script tag has to be added to the page. The
addScriptTag method attaches the
script tag to the HTML page which is already loaded in your browser window. That action causes the
getGeo function to be called and the JSON-encoded data to be passed to the
alert('Latitude = ' + jsonData.ResultSet.Result.Latitude + ' Longitude = ' + jsonData.ResultSet.Result.Longitude);
script tag approach can make life easier in certain scenarios, but, feature-wise, the
XMLHttpRequest object is still a more reliable, flexible, and secure request mechanism (see Table 1).
|Cross-domain browser security enforced?||Yes||No|
|Can receive HTTP status codes?||Yes||No (fails on any HTTP status other than 200)|
|Can send/receive HTTP headers?||Yes||No|
|Offers synchronous and asynchronous calls?||Yes||No (asynchronous only)|
script tag's main advantages are that it is not bound by the web browser's cross-domain security restrictions and that it runs identically on more web browsers than
XMLHttpRequest is available in all the latest browsers, but IE's implementation is somewhat different and requires a compatibility layer (such as Sarissa) to make it work across all browsers.
XMLHttpRequest can receive raw JSON as well as XML, plain text, and HTML -- in fact, it handles any non-binary data easily. It also can send and receive individual HTTP headers, can do both HTTP
POSTs, and supports both synchronous and asynchronous calls. In short, if there's a problem with your web services request, such as invalid XML or a server error, the
XMLHttpRequest gives programmers tools to handle the situation.
In contrast, the
script tag offers few of the
script tag will silently fail.
To be fair,
script tag requests don't actually work exactly the same way across all browsers. The event handling -- how you wait for the tag to load -- is a bit different. Technically, dynamically generated
script tags load asynchronously, but, there is no reliable, cross-platform way to wait for a
script tag to load. Microsoft's IE uses one method described here, while the HTML 4.0 specification suggests the onload event handler, though it doesn't seem to work across all browsers.
The security issues surrounding the
script tag cannot be ignored. Malicious scripts downloaded into your browser run with the same authority as other scripts in your page, so a villainous script can steal your cookies or misuse any authorization that you may have with a server. These villainous scripts can more easily send and receive stolen data using the
script tag. For this reason, applications using the dynamic
script tag approach need to be carefully vetted.
With all of these drawbacks, it is unlikely that programmers will be flocking to implement or re-implement web services requests using
script tags. Still, it's well suited for scripting applications where non-critical data needs to be retrieved from third-party sources easily.
XML.com Copyright © 1998-2006 O'Reilly Media, Inc.