In 2002, Dr. Roy Fielding introduced the topic of Representational State Transfer (REST) as part of a broader dissertation on distributed software architectures. In his thesis, Dr. Fielding, one of the principal authors of the HTTP specification, discussed architecture and design patterns for network-based application structure and design. REST just happened to pop out of the thesis as one of those topics that stirs up as much argument as it does confusion. In the case of REST, the topic itself is relatively obscure, thus any controversy around it is really more of a tempest in a teacup. However, when considering the evolution of geospatial Web services, it turns out that explaining REST and clarifying the discussion suggests the need for a proposal of how to apply REST to geospatial Web services. Such a proposal might help the open source and open standards communities establish better techniques to make geospatial Web services more open and accessible.

I don't GET this POST thing
The definition of the term "Web service" is confused by popular marketing literature. Is the main Google Maps interface a Web service? Technically, it is not. Does the Open Geospatial Consortium (OGC) Web Map Service (WMS) standard describe a Web service? Absolutely.

A service is a software component that processes data and returns a recognizable response when queried by a client component that knows how to start the communication and process the response. "Web service" describes a set of software components that communicate over the Internet using published, standardized protocols and messaging languages. Web services may provide information about themselves when queried by a client application and may be invoked for complex operations by a variety of applications without having to exchange information about hardware or software platforms. Geospatial Web services involve the exchange and processing of data with a spatial component.

Beyond the obvious debate that must take place over the contents of standardized messaging languages, additional controversy arises when you examine the method by which requests are sent to a Web service. Two are quite common. In one method, called POST, the Web request appears to be a simple URL, but actually includes hidden metadata that describes the request details. A POST-type request could be used when you surf to a page that shows a new red Ferrari Enzo in a fictitious online catalog. The URL you see in your browser might look like this:

http://www. postmethodmotors.com/display.py

The following URL might be seen when you surf to the page to look at a Learjet 23 plane from the same company:

http://www.postmethodmotors.com/display.py

See the difference? Exactly. In a POST-type request, all of the important information about the product is hidden in the metadata that accompanied the request, so the requests look identical. These calls are also often referred to as "SOAP" Web service requests because SOAP (Simple Object Access Protocol) can be thought of as a standardized way of putting metadata in POST requests.

The second popular method, the GET method of making Web requests, puts all the information about the request in the URL. Researching that red Enzo at a different online company might result in the following URL:

http://www.getmethodmotors.com/display.py?type=auto&make=ferrari&model=Enzo& color=red

The request for the jet at the same company might look like this:

http://www.getmethodmotors.com/display.py?type=plane&make=learjet&model=23

This company uses GET-type URLs for Web requests. Many in the IT and geospatial communities mistakenly call these GET types of URLs "REST" or "RESTful" URL calls. The information that determines which item you want to order is plainly visible in a GET-type URL. Some developers prefer GET-type URLs because they are unique and because a human might be able to read and manipulate them. The detailed information contained in POST-type requests is simply not visible in the URL, thus may not be manipulated or saved by the Web surfer. In real world applications, GET-type URLs may become extremely complicated with large key-value parameter lists, making them only marginally more useful than POST-type URLs to the human reader.

Standards to confuse you
At first glance, much of the debate over "REST" in the geospatial community appears to focus on whether or not to make POST or GET Web requests. But REST isn't the same as GET and much of this confusion arises because the OGC developed a standard for making GET-type Web service calls before either SOAP or REST were formalized.

Naturally, when the broader IT industry decided to catch up with the geospatial community, the IT industry introduced standards that confused the geospatial vernacular when the newly introduced terms were not well understood by developers.

SOAP turns out to be a bit more than just POST. SOAP actually encapsulates a method for communicating with a complex service such that the client actually knows some details about how the Web service works. The use of SOAP favors complex application architectures that build automation intelligence into how services intercommunicate.

REST, of course, turns out to be more than simply renaming the GET request method. As part of a much broader discussion, Dr. Fielding introduced REST to suggest a pattern for making GET requests more transparent and intuitive to the human reader. The proposal that Dr. Fielding introduced also forces the application designer to consider the structure of information that is sent to a service by way of a URL. REST encapsulates information in the URL in a manner that frees the developer or Web surfer from having to know intimate details about how the Web service is constructed.

The practical use of applying REST results in URLs that intuitively display the request parameters. Like most GET URLs, a REST-styled URL is unique and may be saved because it is also useful as a reference to the response that was displayed in the browser after the Web service request.

SOAP, as a protocol, and REST, as a style, offer legitimate alternatives for designing an architecture to access Web services. REST, however, presents a surprisingly intuitive picture of accessing a service to retrieve data. A REST URL to access an online catalog page for that Enzo might look like this:

http://www.reststylemotors.com/display/auto/ferrari/Enzo/red

The REST request for the Learjet might look like this:

http://www.reststylemotors.com/display/plane/Learjet/23

The server is able to interpret the URL to understand that the catalog service is supposed to display a red sports car versus a Lear jet. A human can also interpret the URL and, if necessary, manually change the URL to look for a Learjet 35A by making a simple edit. For example:

http://www.reststylemotors.com/display/plane/Learjet/35A

The application designer has structured the URL interpretation such that a Web surfer or an application designer can intuit the URL component meanings and adjust the URL to search for other catalog items. REST-style URLs are particularly useful for users with vision disabilities when hyperlinks don't have useful explanatory metadata. Many search engines have an easier time interpreting REST URLs than POST URLs or GET URLs that contain many parameters. (Note that, in complex applications, even REST URLs may employ long key-value parameter strings.)

The server doesn't actually contain a Web page for every unique URL combination in a RESTful system. Instead, the server uses a magical technique, called URL rewriting, to convert the URL to a differently structured request that can be processed by a script. REST lends itself well to content management systems, document management systems, blogs and catalogs that can benefit from the retrieval of complex information from a database in an intuitive manner. It also helps that GET-type URLs, like REST URLs, can be saved and retrieved, unlike a POST-based system, such as SOAP.

But can REST be applied to geospatial Web services?

I'm getting no REST here
Many geospatial technologists will suggest that OGC WMS requests are an example of REST. Here is an example WMS format request that might be used with standards-compliant applications such as MapGuide Open Source and UMN MapServer:

http://www.someogcserver.com/geoserver/wms?VERSION=1.1.1&REQUEST=
GetMap&SERVICE=WMS&LAYERS=massgis:GISDATA.TOWNS_POLYM,massgis:
GISDATA.NAVTEQRDS_ARC,massgis:GISDATA.NAVTEQRDS_ARC_INT&SRS=
EPSG:26986&BBOX=232325.38526025353,898705.3447384972,238934.49648710093,903749.
1401484597&WIDTH=570&HEIGHT=435&FORMAT=image/png&STYLES=Black_Lines,
GISDATA.NAVTEQRDS_ARC::ForOrthos,GISDATA.NAVTEQRDS_ARC_INT::
Default&TRANSPARENT=TRUE

From publicly available online documentation, we can examine an example of ESRI's proprietary ArcWeb Services "REST" format:

http://www.arcwebservices.com/services/v2006_1/restmap?actn=getMap&usrid=
abcde12345&c=117.58657|33.99326&ds=ArcWeb:TA.Streets.US&sf=116200

Neither URL is formatted in a REST style nor is either URL human-readable. In fact, if you looked at the metadata in analogous POST requests, the key value pairs might look nearly identical to what appears in these URLs. Whether the geospatial community standardizes on GET-type Web requests or POST-type Web requests, a closer examination of REST shows that the discussion should perhaps be centered on how information in service requests is structured such that maps and spatial analyses can be retrieved in a more intuitive, accessible manner.

Many in the geospatial industry might suggest that adapting REST to map requests is too difficult given the complexity of a detailed map request. However, even well accepted standards such as WMS may require simplification in some use cases. For example, the inclusion of a presentation service as part of the OpenLS OGC specification suggests that mobile and LBS applications may benefit from a lighter data request standard than WMS.

The demand for rapid access to maps and analyses with common styles, standard themes, and repeated calculations presents opportunities for the simplification and consolidation of geospatial service requests within an architecture that is more intuitive for programmers and users alike. Access to read-only consumer applications such as map books, map catalogs and public planning websites maps might be improved by adding REST-style URL access to the Web application that serves them. More complex applications would also benefit from better organization of how requests and data flow back and forth between client and server.

As REST is a style that would open up geospatial Web services in a more intuitive information and communication architecture, I don't expect corporate entities to pioneer REST in the geospatial arena. Neither do I believe that the OGC has the agility to easily adopt a REST-based request standard that is so different from the existing OGC standard request styles. However, the opportunity to standardize an information architecture for geospatial service requests should pique OGC's interest.

The most likely creator of a REST-styled standard for accessing geospatial Web services will be the open source geospatial community. As the industry moves toward increasing demand for standardized data access, categorization, and map retrieval, some smart research group will probably strike upon an obvious, but intuitive adaptation of REST that will open up geospatial Web services to the consumer applications market place. Such a format would complement initiatives such as the Public Geospatial Data Committee.

Until then, I don't have much of an opinion about whether the industry should standardize on POST or GET request types. Both types of request use predictable, standardized formats that can be executed elegantly or poorly. The REST discussion reveals that the industry should consider that predictability is not the only goal of standards. Intuitiveness and accessibility may be equally important when establishing information exchange standards.

Acknowledgements
The author thanks Nathan McIntyre of DigitalGlobe for initial ideas and helpful comments.