Currently the Web ADF does not include an ArcGIS Server data source that supports consuming ArcGIS Server services via REST. Instead, the pre-packaged ArcGIS Server Internet data source uses the SOAP API to consume ArcGIS Server services. From a platform perspective, this makes sense because the Web ADF is founded in a rich, server-side ASP.NET development environment where SOAP provides some clear benefits. Let’s look at this topic in more detail…
The key difference between the use of REST and SOAP lies in the WSDL. The WSDL provides a central, language agnostic means for defining how to interact with a SOAP service. Different development environments can use the WSDL to construct the same set of types on-the-fly using a SOAP toolkit. REST does not define a compliment to the WSDL. As a result, documentation must be used to determine request and response content. Technically, you can manually construct a proxy and set of types to interact with a REST service, but without a central definition or standard (provided by a WSDL) the API structure will likely differ between developers.
The sample is available here.
There are a few caveats:
1) The layer (i.e. resource) is only available on the client; server components do not know about it. As a result, any requests to the server that work with map resources will not include this layer. In addition, most ADF controls require modification on the server to change their rendered content. This includes the Toc, so if you want the pure client layer to show up in an ADF Toc, you’ll need to customize Toc content using code on the server.
In the sample I provided, if a proxy (via the proxyUrl property) is defined when creating a new DynamicRestLayer, the proxy will be used. In this case, a POST request is always generated to guarantee that all the input arguments are passed to the remote site. The response is JSON and contains the properties of the generated map image, including the url and extent. If no proxy is specified for the DynamicRestLayer, a simple GET request for a map image is made via a dynamic image tag. The image tag source is not subject to cross-site scripting restrictions in the browser, so we don’t need a proxy. Both IE7 and FireFox 2+ work great with the no proxy solution. Unfortunately IE6 is somewhat problematic (e.g. triggers erroneous requests). If you need to support IE6, you may want to go the proxy route.
Note, the sample also shows how to use REST to access tiles in a cached map service with a pure client layer. It may be of interest since the url is standard across sites (e.g. you don’t need to know the virtual cache directory).