The bottom line is that services used to implement the back end of an ASP.NET AJAX system are specific and local to the application. They are implemented as ASP.NET Web services only because that was the only service-based API available when ASP.NET AJAX was planned. In ASP.NET 3.5, in fact, you can drop entirely the ASP.NET Web service model and fully embrace the WCF programming model. The reason why this requires version 3.5 of the .NET Framework and is not supported on, say, version 3.0 is that WCF version 3.0 didn’t include ad hoc support for JSON.
A script service receives input data and sends return values back using a JSON stream. So the service infrastructure must be able to deserialize JSON strings to platform-specific objects and, vice versa, it must be powerful enough to serialize objects to JSON strings.
AJAX script services decorated with the ScriptService attribute are still callable from any code in the universe that has access to the ASMX endpoint and that knows how to handle SOAP. Take a look at Figure 3.
Figure 3: Double access to an ASMX endpoint
Any script service is potentially dual and can be accessed either via JSON or SOAP. Why is it so? Because in ASP.NET AJAX, a script service is implemented via the ASP.NET Web service interface and automatically gets to support a variety of calling protocols. The same happens for WCF services. However, both Web and WCF services offer a number of configuration options through which you decide bindings and behaviors. If you simply want your ASP.NET Web service, exposed as a script service, to be accessible only by JSON callers, then all that you have to do is adding the following markup to the web.config file of the hosting application:
<webServices>
<protocols>
<clear />
</protocols>
</webServices>
If you’re even a little bit familiar with the ASP.NET configuration schema, you should grasp the sense of the markup. ASMX Web services do not support any protocols implemented through the standard ASP.NET handler: no HTTP POST, HTTP GET, SOAP over HTTP POST, not even the Documentation protocol used locally to test Web services. Given the preceding settings, the service can only be accessed outside the standard ASP.NET Web service handler – that is, only via JSON and from ASP.NET AJAX pages.
Operating script services
Created as ASP.NET Web services, AJAX script services are invoked from within JavaScript proxy classes. A proxy class for a given service is automatically generated and linked to the page whenever a service is referenced with the page’s script manager, as below:
<asp:ScriptManager runat=”server”
id=”ScriptManager1”>
<asp:ScriptReference
path=”service.asmx” />
</asp:ScriptManager>
Calls sent through the proxy use the HTTP verb specified in the definition of the service class. By default, the HTTP POST verb is used to transport parameters and return values as JSON strings. However, by adding an optional [ScriptMethod] attribute to individual methods in the service you can force the use of the HTTP GET verb and XML serialization. The arguments you can use with the [ScriptMethod] attribute are described in Table 1.
| Table 1 – Parameters for the [ScriptMethod] attribute | |
| Parameter | Description |
| ResponseFormat | Specifies whether the response will be serialized as JSON or as XML. JSON is the default format. |
| UseHttpGet | Indicates whether a HTTP GET verb can be used to invoke the Web service method. HTTP POST is used by default. Note that opting for HTTP GET raises some serious security concerns. It makes it virtually possible for an attacker to call the method’s URL via an injected <script> tag thus automatically uploading any sensitive local cookies to the source of the <script> tag – the attacker’s Web site. |
| XmlSerializeString | Indicates whether all return types, including strings, are to be serialized as XML. The default is false. |
Unless the default configuration is changed, the ASP.NET AJAX transportation mechanism uses HTTP POST throughout to carry JSON strings. To what extent, is this approach REST-ful?
Comments