[an error occurred while processing this directive][an error occurred while processing this directive]
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.
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:
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?
In addition, while RESTful architectures are definitely high performing (usually), all this chatter on the wire suffers from latency—latency in transfer and latency in serialization/deserialization at the endpoints. There is a better way.
Getting Your REST, and Still Getting Something Done
Consider the diagram in Figure 3. It shows an alternative solution to the developer's functional problem previously described while remaining RESTful to the consuming client.
Let's take a closer look at what's going on.
What It Gets You
In short, the six-step GIS process described at the beginning of this article has been abridged to "Here's a point, hand me a road segment and a mile marker." The architecture has transferred what would have been client workload into an MVC Controller class and a Web service on the server side, reducing chatter on the wire and increasing performance. GIS operations have been turned over to custom ArcObjects code (read: fast). In addition, two other important things have been achieved through this architecture:
The presence of SOAP, WS-*, and ADF in an architectural diagram for a REST article may raise some eyebrows, but recall that all that matters is how the original resource request looks to the client application. REST prescribes access to information via addressable resources; it does not dictate internal implementation. The client sees a REST resource and gets the answer the user wants quickly.
Much has been written in the Esri realm about the power and usefulness of COM utilities and SOEs. Developers and architects need to remember that the RESTful nature of application architecture need not stop where the Esri REST API toolbox does. That's the beauty of REST: it allows developers to bolt together high-performance, URI-based services and application components that may or may not be of their own making.
Providing server-side components, accessible via a REST resource, in this way is an excellent means of developing focused, user-friendly applications with advanced capabilities not currently available in the ArcGIS Server SOAP and REST APIs. Furthermore, this approach hides complexity from the user, delivers high performance, and represents a simple reorganization of Esri technologies most GeoWeb developers are already used to using. For more information, contact
David Bouwman, CTO and Lead Software Architect
About the Authors
David Bouwman has been designing and developing GIS software for the last 12 years. His projects have ranged from small Web sites to statewide enterprise forest management systems. Over the last few years, he has been leading a team of developers in the pursuit of great software built in a sane manner. The combination of an agile process with pragmatic development practices taken from extreme programming has led his firm to develop a highly optimized methodology for creating solid software. When he is not attached to a computer, Bouwman is often found mountain biking on the trails around Fort Collins.
Brian Noyle originally trained as a global change biologist and tundra botanist. He has nearly 10 years' experience as a GIS software developer and architect. His professional and technical interests are primarily focused on moving clients toward more standard architecture and development practices and patterns to facilitate a closer integration of GIS with the standard IT enterprise. Noyle has extensive experience in full software life cycle management with a focus on delivering through agile project management methods. When he's not in the office, he can be found on his mountain bike, picking a bluegrass lick on the guitar, or standing in a river waving a stick (at trout).