Standard Architecture for the GeoWeb: Give it a REST
Author's note: This post was prepared in advance of an architecture panel I will be participating in at the GeoWeb conference July 27-31, 2009 in Vancouver. At the request of conference organizers, myself and the other panel participants have all prepared posts on our "pet" architectural style. This year I drew the REST straw while Ian Painter of Snowflake Software will vigorously defend SOAP/RPC and Hans Shoebach of Galdos Systems will do battle for P2P/Event Driven architecture. This post will be cross posted over on the GeoWeb 2009 blog as well.
The Geospatial Web, the current darling of location based technologies and neogeography, has been variously described as:
- web mapping - the generation and publication of highly performant web applications that include a map
- mashups - combining spatial data with abstract information to produce novel representations
- a distributed GIS for the web - essentially the combination of elements of traditional GIS technologies with advanced web development tools
- equivalent or synonymous with relatively new technologies such as Google Earth, Microsoft Bing Maps, Yahoo Maps, etc.
- communal or user-generated geospatial content
While each of these descriptions is both incomplete and an oversimplification, I assert that at its core the GeoWeb is a technical foundation of information services and collaborative tools built upon or merged with data that provide a spatial context...a location. It is indeed shiny "slippy" maps, Web 2.0 application layouts, nano-formats, mashups, LBS, service-based spatial information sharing, but it is also the hardware, software, information architecture, advanced web application techniques, and people who come together to make such an organic endeavor possible.
The number of organizations working with GeoWeb technologies is already large and growing daily. It seems only logical then, that as a community we engage in an open debate about how exactly all of these databases, services, clients, and functionalities are ultimately going to communicate, integrate, and grow. My endeavor, in the context of this post and in preparation for an architecture panel at the GeoWeb 2009 conference, is to espouse Representational State Transfer (REST) as a standard architectural pattern for the GeoWeb. I'll try to keep my points brief here with hope of stimulating discussion that will continue at the GeoWeb conference in Vancouver at the end of July.
