Since I've posted a few jQuery posts recently I've gotten a bunch of feedback to have more content on using jQuery in Ajax scenarios and showing some examples on how to use jQuery to cut out ASP.NET Ajax. In this post I'll show how you can use jQuery to call a WCF REST service without requiring the ASP.NET AJAX ScriptManager and the client scripts that it loads by default. Note although I haven't tried it recently the same approach should also work with ASMX style services.
WCF 3.5 includes REST functionality and one of the features of the new WCF webHttp binding is to return results in a variety of ways that are URL accessible. WCF has always supported plain URL HTTP access, but it's not been real formal and had somewhat limited functionality as parameters had to be encodable as query string parameters. With the webHttp binding there's now an official WCF protocol geared towards providing ASP.NET AJAX JSON compatibility (using WebScript behavior) as well of a slightly cleaner raw JSON implementation (basic webHttp binding).
You can return XML (default), JSON or raw data from WCF REST services. Regardless of content type, natively WCF always wants to return content in a 'wrapped' format which means that both inbound parameters and outbound results are wrapped into an object.
Let's take a look at the message format for a REST JSON service method.
[ServiceContract(Name="StockService",Namespace="JsonStockService")]
public interface IJsonStockService
{
[OperationContract]
[WebInvoke(Method="POST",
BodyStyle=WebMessageBodyStyle.Wrapped,
ResponseFormat=WebMessageFormat.Json
)]
StockQuote GetStockQuote(string symbol);
..
The input message on the wire looks like this:
The response looks like this:
{"GetStockQuoteResult":
{"Company":"MICROSOFT CP",
"LastPrice":30.00,
"LastQuoteTime":
"\/Date(1208559600000-0700)\/",
"LastQuoteTimeString":"Apr 18, 4:00PM",
"NetChange":0.78,
"OpenPrice":29.99,
"Symbol":"MSFT"}
}
Notice that in both cases an object is used. For the inbound data all parameters are wrapped into an object and rather than just passing the value, the name of the parameter becomes a property in the JSON object map that gets sent to the server. This is actually quite useful - if you're just sending a raw JSON structure you could only pass a single parameter to the server - and that option is also available via the Web BodyStyle=WebMessageBodyStyle.Bare option on the service method.
The outbound result set is also wrapped into an object which is a lot less useful. This is a hold over from WCF which wraps all responses into a message result object, which usually makes sense in order to support multiple result values (ie. out parameters etc.). In a Web scenario however this doesn't really buy you much. Nevertheless if you want to pass multiple parameters to the server you have to use this wrapped format along with the result value.
Calling with jQuery
If you're using jQuery and you'd like to call a WCF REST service it's actually quite easy either with bare or wrapped messages. Bare messages are easier to work with since they skip the wrapping shown above, but as I mentioned you're limited to a single input parameter. So if your service has any complexity you'll likely want to use wrapped messages.
You can opt to either call services using the ASP.NET Ajax logic (WebScriptService behavior) or using the raw service functionality which is shown above.
To call these methods with jQuery is fairly straight forward in concept - jQuery includes both low level and highlevel methods that can call a URL and return JSON data. The two methods available are $.getJSON() which automatically parses result JSON data and $.ajax(), which is a lower level function that has many options for making remote calls and returning data.
getJSON() is useful for simple scenarios where the server returns JSON, but it doesn't allow you to pass JSON data TO the server. The only way to send data to the server with getJSON is via query string or POST data that is sent as standard POST key/value pairs. In all but the simplest scenarios getJSON() is not all that useful.
The lower level $.ajax method is more flexible, but even so it still lacks the capability to pass JSON data TO the server. So little extra work and some external JSON support is required to create JSON output on the client as well as dealing with Microsoft Ajax's date formatting.
Personally I prefer to use a wrapper method for making JSON calls to the server to encapsulate this functionality. Note although this method seems somewhat lengthy it deals with a few important issues that you need to take care of when calling WCF REST Services:
// *** Service Calling Proxy Class
function serviceProxy(serviceUrl)
{
var _I = this;
this.serviceUrl = serviceUrl;
// *** Call a wrapped object
this.invoke = function(method,data,callback,error,bare)
{
// *** Convert input data into JSON - REQUIRES Json2.js
var json = JSON2.stringify(data);
// *** The service endpoint URL
var url = _I.serviceUrl + method;
$.ajax( {
url: url,
data: json,
type: "POST",
processData: false,
contentType: "application/json",
timeout: 10000,
dataType: "text", // not "json" we'll parse
success:
function(res)
{
if (!callback) return;
// *** Use json library so we can fix up MS AJAX dates
var result = JSON2.parse(res);
// *** Bare message IS result
if (bare)
{ callback(result); return; }
// *** Wrapped message contains top level object node
// *** strip it off
for(var property in result)
{
callback( result[property] );
break;
}
},
error: function(xhr) {
if (!error) return;
if (xhr.responseText)
{
var err = JSON2.parse(xhr.responseText);
if (err)
error(err);
else
error( { Message: "Unknown server error." })
}
return;
}
});
}
}
// *** Create a static instance
var Proxy = new serviceProxy("JsonStockService.svc/");
WCF services are called by their URL plus the methodname appended in the URL's extra path, so here:
JsonStockService.svc/GetStockQuote
is the URI that determines the service and method that is to be called on it.
The code above uses the core jQuery $.ajax() function which is the 'low level' mechanism for specifying various options. Above I'm telling it to accept raw string input (in JSON format), convert the response from JSON into an object by evaling the result, as well as specifying the content type and timeout. Finally a callback handler and error callback are specified.
Note that I override the success handler here to factor out the wrapped response object so that the value received in the callback handler is really only the result and not the wrapped result object. More on this in a second.
The call for the above StockQuote(symbol) call looks like this (including some app specific code that uses the result data):
var symbol = $("#txtSymbol").val();
Proxy.invoke("GetStockQuote",{ symbol: symbol },
function (result)
{
//var result = serviceResponse.GetStockQuoteResult;
$("#StockName").text( result.Company + " (" + result.Symbol + ")" ) ;
$("#LastPrice").text(result.LastPrice.toFixed(2));
$("#OpenPrice").text(result.OpenPrice.toFixed(2));
$("#QuoteTime").text(result.LastQuoteTimeString);
$("#NetChange").text(result.NetChange.toFixed(2));
// *** if hidden make visible
var sr = $("#divStockQuoteResult:hidden").slideDown("slow");
// *** Also graph it
var stocks = [];
stocks.push(result.Symbol);
var url = GetStockGraphUrl(stocks,result.Company,350,150,2);
$("#imgStockQuoteGraph").attr("src",url);
},
onPageError);
Parameters are passed in as { parm1: "value1", parm2: 120.00 } etc. - you do have to know the parameter names as parameters are matched by name not position.
The result is returned to the inline callback function in the code above and that code assigns the StockQuote data into the document. Notice that the result returned to the callback function is actually NOT a wrapped object. The top level object has been stripped off so the wrapper is not there anymore.
If you look at the the ajaxJSON function, you can see that it looks for the first result property in the actual object that WCF returns and uses IT to call the callback function instead - so it's indirect routing. This saves you from the one line of code commented out above and having to know exactly what that Result message name is ( WCF uses <methodName>Result). Not that one line of code would kill you, but it's definitely cleaner and more portable.
The same approach should also work with ASMX style services BTW which uses the same messaging format.
JSON encoding
Note that the ajaxJSON function requires JSON encoding. jQuery doesn't have any native JSON encoding functionality (which seems a big omission, but was probably done to preserve the small footprint). However there are a number of JSON implementations available. Above I'm using the JSON2.js file from Douglas Crockford to serialize the parameter object map into JSON.
There's another wrinkle though: Date formatting. Take another look at the stock quote returned from WCF:
{"GetStockQuoteResult":
{"Company":"MICROSOFT CP",
"LastPrice":30.00,
"LastQuoteTime":
"\/Date(1208559600000-0700)\/",
"LastQuoteTimeString":"Apr 18, 4:00PM",
"NetChange":0.78,
"OpenPrice":29.99,
"Symbol":"MSFT"}
}
There's no JavaScript date literal and Microsoft engineered a custom date format that is essentially a marked up string. The format is a string that's encoded and contains the standard new Date(milliseconds since 1970) value. But the actual type of the date value in JSON is a string. If you use standard JSON converters the value will be returned as a string exactly as you see it above. I've talked about the date issues, and hacking existing JSON implementations before. I've modified Crockford's JSON2.JS to support the Microsoft date format so it properly encodes in and outbound data. You can download the hacked JSON2_MsDates.zip if you're interested. You can look at the code to see the modifications that were required, which essentially amounts to pre filtering parsed data before evaling on the .toJSON end and dropping the Data format that Date.prototype.toJSON() produces and instead creating a string in the required format above when doing object encoding.
Bare Messages
If you want a cleaner message format and you're content with single parameter inputs to functions then the WebMessageBodyStyle.Bare can work for you. Bare gives you a single JSON parameter you can pass that is automatically mapped to the first and only parameter of a method. You can't use Bare with any service methods (other than GET input) that include more than one parameter - the service will throw an exception when you access any method (beware: it's a RUNTIME error!).
Bare messages are easier to work with but they are limited because of the single parameter. You can use a single parameter on the server and make that input a complex type like an array to simulate multiple parameters. Using input objects or arrays can work for this. While this works realize that WCF requires an exact type match so any input 'wrapper' types you create yourself have to be mappable to a .NET type.
My first instinct with WCF's web bindings was always to use Bare, but ultimately the wrapped format provides more flexibility even if it is a little uglier on the wire. For AJAX services wrapped seems to make more sense.
Ideally, I would have preferred even more control - wrapped input messages and bare output messages, but I guess you can't have everything <g>...
Other Input Alternatives
Passing JSON messages is one thing you can do - the other option is to pass raw POST variables, which is something that can be done natively with jQuery without requiring a JSON encoder. Basically jQuery allows you to specify data as an object map, and it can turn the object into regular encoded POST parameters.
[OperationContract]
[WebInvoke(Method="POST",
BodyStyle=WebMessageBodyStyle.Bare,
ResponseFormat=WebMessageFormat.Json
)]
StockQuote GetStockQuote(string symbol);
You'd also need to mark your class:
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class JsonStockService : StockServiceBase
and enable ASP.NET compatibility in web.config (see my WCF REST Configuration Post for details)
If you prefer the simplified logic and you can use POST input data (which works well if you rather post back to a handler or the same ASPX page) you can get away with the following:
function ajaxJsonPost(method,data,callback,error)
{
var url = "JsonStockService.svc/" + method;
$.ajax( {
url: url,
data: data,
type: "POST",
processData: true,
contentType: "application/json",
timeout: 10000,
dataType: "json",
success: callback,
error: error
});
}
When you send data like this you can actually change the message format to Bare and get just a raw object response. jQuery can either except a raw POST string for the data parameter or an object whose properties and values are turned into POST key value pairs.
If you want to use POST behavior with WCF though, you need to enable ASPNET Compatibility on the REST service - otherwise the HttpContext.Current.Request is not available since WCF REST by default is trying to be host agnostic. For more information on how to configure WCF REST services check my previous post on WCF REST configuration last week.
This format might be preferrable if you are indeed building a public API that will be externally accessed. Raw POST data interchange is more common for many Ajax libraries, and also lends it self to straight HTTP clients that don't have JSON encoding features built in. For public APIs this makes plenty of sense. Remember that if you care about date formatting you may want to add the explicit JSON2 parsing code into the success callback (I left this out here for simplicities sake).
Error Handling
One more issue you'll want to be very careful of with WCF REST Services when you're using non-WebScriptService (ASP.NET AJAX style) behavior: When an error occurs WCF unfortunately throws an HTML error page rather than a JSON or XML fault message. That's a big problem if you want to return meaningful error messages to your client application - the only way to retrieve the error is by parsing the messy and very bulky HTML document returned.I've tried finding some way to get the REST services to throw a full JSON based error message and I haven't found a way to do this. JSON error messages seem to only work when you're using WebScriptService which is the full ASP.NET AJAX emulation. Under WebScriptService behavior the message returns the standard Exception like structure that includes a .Message and .StackTrace property that lets you echo back errors more easily.
In the end this means that even if you are using a non-MS Ajax client it might be the best solution to use the ASP.NET AJAX style WebHttp binding, simply because it provides the behavior that you most commonly require. There's nothing lost by doing so. You don't incur any client ASP.NET AJAX client requirements, but you do get the wrapped format input and exceptions properly wrapped on errors, plus this format is easier to implement because it doesn't require any special attributes on each individual operation/method as it's a fixed format. On the downside you do lose the ability to use UrlTemplates which might be useful in some situations, but it's probably not a common scenario that you need this for pure AJAX services.