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.
REST is Best #1: Adopt the architecture of the medium
Continuing my trend of oversimplication, the GeoWeb is simply the web + geo right? While it is indeed more than just web mapping, at it’s core the GeoWeb commonly leverages the World Wide Web for information access and representation in a client application. The web is the poster child for RESTful architectures as articulated in Roy Fielding’s doctoral dissertation. So the pragmatist in me says that if we’re going to build a network of loosely coupled systems to support the Geospatial Web and we’re going to use the web to provide access, why wouldn’t we leverage the architecture of our good friend “dubya, dubya, dubya”? GET, PUT, POST, and DELETE. The semantics are well defined and well understood (okay, POST can be a little wonky due to issues of idempotency but I think my point holds).
Every single application exposes its resources through exactly the same interface…the HTTP specification. Would you, as a developer of a service or a client rather work with 4 HTTP verbs, or would you rather need to discover, proxy, and understand myriad SOAP contracts? Written a WSDL lately? Read one? I thought so…
REST is Best #2: It’s about resources
REST-based services (or REST resources for my “high-REST” friends in the audience) are true “web services” in every sense of the term since they’re based entirely on HTTP and URIs. Map images of downtown Las Vegas, your running route, drill pad locations, the location of the nearest Starbucks, parcel boundaries, a street level image of some guy mooning the Google van; all just pieces of information when it comes right down to it. What we store, exchange, represent, draw on a map, and recombine into novel information combinations are simply resources…and that’s what REST is all about. Why make it any more complex than it has to be. Why would I POST to a SOAP method or consume an event from a service agent when all I want to know is http://www.myTranspoSite.com/projects/532. (In English: “Get me the location, status, and funding information of the stimulus transportation project going on at the end of my street.”)
“But what about my complex geoprocessing operation,” you say? Well, spatial statistics or complex operations that produce a result (buffer, linear referencing operations, etc.) are all fine and dandy for us technologists, but the GeoWeb isn’t just for GIS professionals anymore. Why expose your client developer, or worse a run of the mill user, to such complexities. A user doesn’t know what a buffer is and neither does the Dojo ninja that’s consuming your resourcein his JavaScript client…they just want to know how many crimes where committed in their neighborhood in the last 6 months. Hide complexity within the REST resource and give a simple answer to a complex question.
In an ROA effectively adhering to a RESTful architecture, all I need to know to get the information I want is a URI and an action. Do I have to negotiate a proxy? Am I getting cached information? Is there a gateway or firewall in the way? How do I negotiate that P2P thingy again? Do I need to do a buffer followed by an intersect followed by a 12th level of hell whatchamacallit? Who cares? Just give me the information I want so I can go play golf, spend time with my kids, wax the car, take a nap, or do any number of other things I’d rather be doing.
REST is Best #3: Serving many masters
The beauty of REST is that you get the standard interface provided by HTTP, with no limitation on data representation. Why is this important for the Geospatial Web? Because browsers like HTML and JSON. Because machines like XML, binary, or code on demand. Humans like pretty pictures and PDFs. And sometime down the line machines and browsers and humans may all change their minds and like some other format. That’s right folks, the GeoWeb ain’t just for browsers anymore and that means we as architects and developers need to keep multiple resource representations foremost in our minds. REST is absolutely critical as an architectural pattern for the GeoWeb because it provides a low friction way for us to provide information formats that better match consuming clients and performance requirements. And as new content types come to light and get defined, REST lets you add support for these novel formats without impacting support for existing/older content types.
REST is Best #4: Now where did I put that..?
So if the GeoWeb is about publishing, consuming, transforming, sharing, visualizing data with a spatial component, it stands to reason that we need a mechanism by which to discover said information. And we’d probably also like a way to get back to the information once we’ve been there once. Or send it to our boss, or forward it to grandma, or shoot it out the list-serv that we’re on.
In short, REST makes the information driving the GeoWeb portable. Once I find a resource I like I can bookmark it to return later, I can throw it in an email and share it with others, I can embed it in my application to be consumed and acted upon in novel ways. It also means that we don’t need a separate discovery mechanism for our resources because resources can be embedded as content in other resources. A country resource can provide information on state resources which can provide information on county resources, etc. Imagine that; an entire network of information and functional resources interconnected by URIs…huh.
REST is Best #5: Performance and Scalability
For most RESTful services (I know, I know…resources) the majority of requests to the resource are probably GET requests. Do I have numbers to back that up? Of course not…I’m an architect. But the logic of the assertion is that presumably many more people are allowed to read/view information than are allowed to create, update, or delete information. Even in scenarios with lots of resource editors, the GET is still likely to far exceed PUT, POST, and DELETE request counts. One of the central tenets of the REST architectural style is that whenever possible, information should be cached. REST gets it’s performance and scalability from this cache-ability, coupled with statelessness.
What this means for the GeoWeb is that we can cache GET requests against a resource. Thus if I visit a resource URL and ask for information on a highway project, and 2 seconds later my neighbor asks for information on the same project…my GET results will be cached so that my neighbor’s request does not incur the penalty of a database hit, business logic enforcement, object formatting, etc. Does it matter for a system with 100 users on appropriately sized servers? Probably not. Does it matter for a large interconnected network of resources with hundreds of thousands or millions of users? You betcha’.
Statelessness means that a server hosting data or functionalities for the GeoWeb should service requests in a manner that does not depend on context or state between requests or between services. If you say to a REST resource, “Give me a map of all preschools within 5 miles of my home”. You cannot simply make a follow up requests that says “Now buffer them”. The statelessness of the resource on the server means it no longer remembers anything about the 20 preschool points it just handed you as JSON…in fact, the server doesn’t even know who you are anymore and wants your credentials again. Why is this good? Because RESTful architectures don’t typically have to contend with maintenance of session state, a server can be swapped out with another in the event of a failure, a sys admin can decide to add three new servers to a farm on Wednesday without existing clients knowing any different, or a group of servers can be allocated to service different types of requests.
Caching and statelessness = performance and scalability all in one neat little package. Sort of a big deal for people building LOB or otherwise critical applications for the GeoWeb dontchathink?
Parting Shots
Did I miss something in my initial hypothesis that REST is the critical architectural style for the GeoWeb? Probably. Did I get something wrong or use semantics likely to raise the hackles of true, dyed-in-the-wool RESTafarians? Probably…I tend to be more pragmatism than dogma anyway. Consider joining us for GeoWeb 2009 July 27-31 and see if I can avoid making a complete fool out myself whilst fighting the good fight to make RESTful architectures an integrated part of the evolving GeoWeb. Find a glaring hole in my argument or something I missed? Leave a comment here so I can study up before doing battle with the SOA/SOAP and P2P/Event Driven folks in July.
[...] finally moving on from the era of exposing buckets of complex GIS functionalities in the browser. As noted in a previous post, the GeoWeb is, in essence, all things Web 2.0 writ large on a map. For ESRI customers it is REST, [...]