Less Chatter, More Work RESTful architectures and heavy lifting with ArcGIS Server By David Bouwman and Brian Noyle, DTSAgile Representational State Transfer (REST) has become one of the darling architectural principles of the technology community of late. The central principles of a RESTful architecture focus on the use of addressable resources in standard resource formats. The HTTP protocol provides the interface for interacting with those resources (via the four HTTP verbs: GET, PUT, POST, DELETE). There is no greater argument for the success and appeal of REST architectural principles for the geodeveloper than Esri's embracing of REST in its release of the ArcGIS Server REST API at version 9.3. While the ArcGIS Server REST API provides a concise and intuitive API for use in the construction of high-performance, client-focused GeoWeb applications, there are times when the use of this API either doesn't offer the functionality needed to accomplish a required function or the REST API is not optimal for accomplishing that function. ArcGIS Server API (COM/DCOM) Point Buffer Web Client Reproject Intersect Linear Distance Clip Find Mile Marker ArcGIS Server REST API Figure 2: A classic example of calls to server-side resources in a "chatty REST" application ArcGIS Server SOAP API ArcGIS Server REST API Figure 1: The functional hierarchy of the ArcGIS Server-side APIs What You Can't Do and What You Can Do Better An examination of the functionalities exposed by the ArcGIS Server-side APIs reveals the hierarchy of relative functional richness illustrated in Figure 1. The ArcGIS Server SOAP API offers a subset (albeit a very large one) of the aggregate functionality offered by ArcGIS Server, while the ArcGIS Server REST API offers a subset (and still a pretty impressive one) of the functionality exposed by the SOAP API. 36 ArcUser Summer 2009 Not surprisingly, there are simply some tasks the developer cannot accomplish via the REST API. Geodevelopers frequently need an alternative solution that will keep their RESTful architecture intact while still allowing them to meet system functional requirements. In addition, consider the following scenario: a developer needs to implement functions that allow a non-GIS user to locate a point along a linear feature by clicking on a Web map with a minimum of friction and limited exposure to GIS operations. The actual GIS involved in this theoretical operation might look something like this: 1. Take a user-specified point and buffer it. 2. Reproject the buffer to a different spatial reference and hold on to the geometry. 3. Use the reprojected buffer geometry to intersect a roads layer and get a road. 4. Use the road polyline geometry and find the distance along the road where the buffer first touches it. 5. Use the distance to clip the road polyline to produce a new polyline feature describing the affected road feature up to the point of intersection. 6. Return the polyline geometry and the distance along the polyline to the client for rendering. This is just an example to make a point, but it makes that point well. The RESTful calls to server-side resources are represented in the diagram in Figure 2. This is the classic example of "chatty REST." Why is this an issue? Non-GIS users (a transportation manager in this scenario) do not care about the specific operations involved in helping them do their job. They want to click the map, have a portion of a road segment become highlighted, and see a mile marker value. With so much going on in the client, business logic is bound to slip in: When the client gets one of these individual responses back, how does the response get validated before continuing along the operation chain? How will this code be unit tested if it resides in the client? www.esri.com