December 21, 2005
provide significant relief. In fact, if you make web services requests using the dynamic
callback function -- you can have unfettered access to the web service in a seamless,
cross-domain, cross-browser fashion.
Here's what you need to try out this dynamic
script tag request:
- Access to a web service that returns JSON and lets you specify a callback function
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.
The KISS Factor
Compared to using the
XMLHttpRequest object and a proxy, this stuff is easy.
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
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):
tag). For comparison, look at the XML version of this call here.
buildScriptTag method of the
JSONscriptRequest object builds
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
getGeo function. Now comes the magic part of the script -- it's a side effect
of using JSON-encoded data instead of XML. When a string of JSON-encoded data is used
reference the data immediately:
alert('Latitude = ' + jsonData.ResultSet.Result.Latitude + ' Longitude = ' + jsonData.ResultSet.Result.Longitude);
Pros and Cons
script tag is the last frontier of unfettered access for
browser-based applications. Depending on your viewpoint, it's either a gaping security
or a tool to make rich clients even richer. Its most common use, though, is by internet
advertisers who use it to pull their colorful ads into your web page. For the average
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
XMLHttpRequest. Further, if your web service happens to offer JSON output and
applications without having to parse the returned data.
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
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
supports both synchronous and asynchronous calls. In short, if there's a problem with
web services request, such as invalid XML or a server error, the
gives programmers tools to handle the situation.
In contrast, the
script tag offers few of the
capabilities. The most notable downside is that it cannot handle errors gracefully.
script tag, a
to the callback function. If your web service returns an HTTP return code other than
(successful), then 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
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
page, so a villainous script can steal your cookies or misuse any authorization that
have with a server. These villainous scripts can more easily send and receive stolen
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.