There are several blog posts out there that cover the subject of how to consume JSON enabled services from Javascript using ASP.net AJAX. Having scouted around the usual suspects, I think the best article is by Fritz Onion here:
http://www.pluralsight.com/blogs/fritz/archive/2008/01/31/50121.aspx
That said, I haven't found it all plain sailing, so I thought I'd write a blog entry covering the issues I have had to overcome in order to get this functionality working.
Service contract namespace issues
You will see from the article above that setting the namespace in the service contract attribute affects the Javascript namespace ASP.net's auto generated Javascript proxy uses to call the service. So, for example, when you use the namespace http://schemas.conchango.com/myservice/, you would instantiate a client proxy in Javascript using the following code:
var proxy = new schemas.conchango.com.myservice.IMyServiceContract;
where IMyServiceContract is the name of the service contract you are instantiating. Notice that the forward slashed are turned into dot notation by the Javascript proxy generation (and the final forward slash does matter!).
Now this all makes a lot of sense so far, until I introduced schema versioning into my namespace:
http://schemas.conchango.com/2008/03/myservice/
Versioning a schema in this way is standard practice for self describing SOAP services that expose a WSDL. It is important to ensure that you can version your service contract safely, ensuring that you don't break any consuming clients when you update your service to include new and changed functionality. It is also fundamental to publish-subscribe middleware, such as BizTalk understands who subscribes to the published message.
Here a hardnosed RESTafarian may well point out that my WCF endpoint exposed using a WebHttpBinding is indeed not a SOAP service, so this is not important. And they are right, so long as I never want to expose my WCF service through an additional SOAP based endpoint (using a binding such as BasicHttpBinding). This is one on the single most important principles of WCF and Service Orientation: to be able to expose a single service, hosted as a single instance through different endpoints so that you can communicate using different transports, encodings and security. In other words, services should be policy driven.
So I did work around the problem; when I need to version my schema I would use a new namespace such as:
http://schemas.conchango.com/myservice2/
I think this is acceptable, although not standard schema naming practice. At least I can now version my schemas properly and expose my service through SOAP and REST at the same time.
Debugging issues with IIS
In order to use ASP.net debugging with ASP.net websites and services hosted in IIS, Visual Studio requires Integrated Windows Authentication to be enabled. However, if you are developing a web site for anonymous access, you will need to enable anonymous access in IIS too. The problem here is that WCF only allows one authentication scheme to be used. If you attempt to debug a service in IIS under these conditions, you will see the following error message:
IIS specified authentication schemes 'IntegratedWindowsAuthentication, Anonymous', but the binding only supports specification of exactly one authentication scheme. Valid authentication schemes are Digest, Negotiate, NTLM, Basic, or Anonymous. Change the IIS settings so that only a single authentication scheme is used.
The simplest workaround to this problem is to switch from using IIS to Visual Studio's development web server. Otherwise I found that I was limited to running the site in IIS.