REST from a GIS developer’s perspective

Posted by Ajay

Lately I have been instrumental in converting our GIS web based functionality into more modularized service based functionality. A year back, our application had a very tightly coupled custom built WMS/WFS server. Imagine being constrained to only using the client that our web application provided, imagine a rogue application that did not follow the WMS/WFS specification, thats what we had - a tightly coupled rogue. This was fine as long as we serviced just one client. But we could not hope to market our product unless we could shift to a more service oriented framework, or atleast a more modular one.

That is when we envisioned the idea to make our GIS more service oriented and modular. This laid the beginning of our trailblazing path towards geoserverization. Now after a couple of months of effort we have a WMS/WFS server that can be used as a GIS service from any client the user prefers to use. All was nice and dandy with this world. Until the day the user wanted more.

One fine day our users decided they wanted to edit the layers on the fly. They wanted to change layer styles through an admin interface in our web application. They even went all the way to asking us to provide functionality, in the admin GUI, to allow them to modify a layer’s data and update it on the fly, as the application was running. Guess who came to my rescue, none other than the REST functionality packaged within geoserver. The rest of this post gives you an introduction to REST and a quick info about geoserver’s REST interface and how I implemented our functionality using REST.

What are thou REST ?

REST or Representational State Transfer is an architectural style, it is not a design pattern nor a true architecture, but just a style, a set of rules that any architecture should conform to. It defines a common interface set that any REST based design can interpret and use. REST revolves around the use of URIs and the use of the HTTP protocol.

REST provides a lot of inbuilt security safeguards since the method that is used can be an indicator of the action that is to be performed – a GET is safe, POST, PUT and DELETE are relatively unsafe. REST provides authorization and authentication through the web server’s inbuilt functionality.

Key Concepts in REST

1. Application state is called as a resource and is identified by a URI. Resources communicate through a standard interface, HTTP. Ex: book is a resource concept. http://myserver.com/book is the URI that returns a file which is a representation of the book resource.
2. Information about a resource is called state and is encoded as part of the resource; these encodings along with the resource are called representations of the resource. Ex: http://myserver.com/book/book1 with an Accept header of text/xml is a particular representation of the resource, which returns the data as XML.
3. Representations are linked together through hypermedia or links. Ex: I can access readers of a book as follows: http://myserver.com/book/users
4. Invoking a REST interface method transfers the state of the resource through representations.
5. The key set of standard interactions are
   • GET – it says give me the information in my chosen format
   • POST – it says add information that I give you
   • PUT – it says replace my information with what you have currently
   • DELETE - it says delete the information that you have

6. REST can evolve with the standard interactions staying the same, new document types can be created and yet the interactions stay the same.
7. It extends the statelessness that HTTP provides, every request is completely encapsulated to perform it’s task independent of previous tasks

REST and Geoserver

Geoserver has been providing a very efficient REST based interface to allow access to geoserver’s admin functionality. Geoserver’s REST defines the following key concepts:

1. workspace – A group of data stores and feature types. This is equivalent to a namespace.
2. datastore – A source of vector based spatial data. It may be a PostGis datastore, shapefile or even a WFS server.
3. featuretypes – A vector spatial resource that originates from a data store
4. coveragestore – A source of raster based spatial data.
5. coverages – A raster based dataset with a coveragestore as the data store
6. styles – describe how a resource should be symbolized or rendered
7. layers – it is a published resource, equivalent to a feature type or coverage
8. layergroups – grouping of layers accessible under a single resource name

One of the key aspects of using REST in my project was to implement two major functionalities:

Provide users a way to dynamically set user styles on the fly.

There are many ways to implement this. The WMS specification allows for SLD and SLD_BODY parameters to be provided as part of the GetMap request. Unfortunately these two methodologies would not work if users store their data in a database. One of the main problems with the SLD parameter is that it requires a SLD file to be created on the server, on the fly which was not an option for us. So. Moving on to SLD_BODY. I was so happy when I implemented this, and it worked, ooooh but I got happy a bit too early. Unfortunately for me I hit upon a restriction in IE, the dreaded GET request length, something I did not even think of since I primarily use Firefox, but unfortunately users use IE. Finally I decide to settle on using the REST interface provided with geoserver.

I decided to use Jersey as my RESTful client API. Jersey builds on a builder pattern to simplify the task of creating a Client, Resources and invoking the RESTful methods, all in a couple of lines of code. At it’s base it uses apache’s HttpClient to perform it’s task with multithreaded efficiency.

A simple PUT as follows:

PUT http://myserver/geoserver/rest/styles/layerName with the SLD string as the request body performed the work for me – modify existing layer’s style with the new style information.

Status codes play a big role in defining how the process was performed. The major ones to be really concerned about are

• 200 – OK - if GET, PUT executed fine
• 201 – Created – if POST executed fine
• 403, 404, 405 – if resource could not be updated for some reason

Allow users to be able to modify a layer

Imagine that you have an application and the user wants to be able to modify a layer on the fly, maybe he has his own data that he wants to upload. Now imagine a restriction that you cannot use the geoserver admin interface. How would you do this? REST baby REST!!

My requirement was to change the originating datastore from a postgis to a shapefile. This was as easy as a PUT to create a new datastore, a DELETE to delete the existing the featuretype and layer, a POST to create a new featuretype, tadaaa…, as easy as pie, all courtesy of the REST API.

How is REST different from RPC

• RPC application is exposed as a network object with one or more exposed public functions, so before communication client must have information about the network object. In REST, this is accomplished through hyperlink relations between objects. RPC uses named operations while REST uses named resources.
• RPC like SOAP can have support for multiple protocols, REST depends on HTTP.
• RPC invariably involves some concept of transaction like WS-AtomicTransaction, REST on the other hand follows HTTP phiolosophy, i.e. deal with failures through retries
• REST provide more diverse formats like JSON,a dn better scalability since it can be cached, SOAP requests cannot be cached

References

1. http://rest.blueoxen.net/cgi-bin/wiki.pl
2. http://tomayko.com/writings/rest-to-my-wife
3. http://en.wikipedia.org/wiki/Representational_State_Transfer
4. http://www.infoq.com/articles/rest-introduction

Tags: gis, java, jersey, REST