Emerging Technology: Geospatial Web Services and REST
Christopher J. Andrews
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
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:
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:
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
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:
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:
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
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:
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
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
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.
The author thanks Nathan McIntyre of DigitalGlobe for initial ideas and