Web services are an integral part of creating most enterprise-level web applications these days. They provide access to services that can't be accessed directly on the client side due to security restrictions. For example, you could have a web service that accesses a database to retrieve or store customer information. Web services can also provide centralized operations that can be accessed from many different applications. For example, a service that supplies weather data.
Web services can be created using any server side technology that can get a web request and return a response. It could be as simple as PHP, or as sophisticated as a service-oriented architecture such as .NET's WCF API. If you are the only one using your web service then PHP may be sufficient; if a web services is designed for public consumption, then maybe not.
Most web services provide data in either XML or JSON format. In the past, XML was the format of choice for web services. However, in recent years JSON has become very popular. Not only because more and more JavaScript applications are interacting directly with web services, but also because it is a succinct, easy-to-read, and easy-to-parse format. Many service providers are now switching over to JSON.
It is not in the scope of this book to teach you how to write web services, but we will learn how to interact with them by using a web service that provides localized weather reports.
For this example we will get the weather from a real web service. We will use the service provided by Weather Underground at http://www.wunderground.com. To run the example code you will need a developer API key, which can be obtained for free at http://www.wunderground.com/weather/api/. The free developer plan allows you to call their services, but limits the number of service calls you can make per day.
We can call a web service using any of the jQuery Ajax methods discussed in the previous sections. There is no problem calling web services that reside in the same domain as your web page. However, calling web services that exist in another domain presents a security problem. This is known as cross-site scripting, or XSS. For example, the page at http://mysite.com/myPage.html can't access any content from http://yoursite.com.
The problem with cross-site scripting is that hackers can inject client-side scripts into a request that will allow them to run malicious code in the user's browser. So how do we get around this restriction? We can use a communication technique known as JSONP, which stands for JSON with Padding.
JSONP works due to the fact that there is a security exception for loading JavaScript files from other domains. So in order to get around the restriction of getting plain JSON formatted data, JSONP simulates a <script> request. The server returns the JSON data wrapped in a JavaScript function call. If we take the JSON from the previous example and put it in a JSONP response, it will look something like the following code snippet:
jQuery18107425144074950367_1365363393321(
{
"location": {
"city":"Your City"
}
,"current_observation": {
"weather":"Clear",
"temperature_string":"38.3 F (3.5 C)",
"wind_string":"From the WSW at 1.0 MPH Gusting to 5.0 MPH",
"feelslike_string":"38 F (3 C)",
"relative_humidity":"71%",
"icon_url":"images/nt_clear.gif"
}
}
);The great thing about using jQuery to make our Ajax requests is that we don't even have to think about how JSONP works. All we need to know is that we need to use it when calling services in other domains. To tell jQuery to use JSONP we pass in a dataType parameter set to "jsonp" to the ajax() method.
The ajax() method can take in an object of name/value pairs that contains all of the parameters for making a request, including the URL. We put our dataType parameter in that object:
$.ajax({
url: "http://otherSite/serviceCall",
dataType : "jsonp"
});