Designing an API for spatial data

I am considering trying to make an API so that I can make some spatial datasets available to colleagues for analysis.

Part of my work has been to analyze and prepare data which can then be used for further analysis by others. The work (while currently at a smaller scale and less sophisticated) is similar to walkscore but does involve some enormous datasets. There are increasing restrictions on how I can share the original data, but my derivative work is shareable. I have been thinking about about how best to share the results of my analysis (outside of passing on large datasets) and thought that an API would be one approach. What sort of things, should I be thinking about when constructing an API? Are there design specifications that I can follow?

My vision sounds a little more grandiose than it currently is, but I think it would be a useful framework to consider early on in this work.

Answer

By API, I presume you mean some sort of network access to your data through an HTTP POST/GET type affair such as the Google Maps API? Will it be raster or vector data? I'll assume vector for the purposes of this discussion. This is really just a communication protocol rather than an Application Programming Interface.

You won't need to design anything from scratch, because there are plenty of standard protocols (rather than APIs per se, I have a bit of a bugbear about calling things APIs when they're not, but I won't bore you!). If you are just interested in serving read-only vector data to your clients, you just need a WFS Server that sits in front of your database. I've used GeoServer in the past, but I prefer the lightweigtness of TinyOWS. Both do the same job: configure them to access your database of derived data, set them running as part of a web server (Apache is common, but I prefer lighttpd), and there you have it. QGIS can load data from a WFS server, and doubtless so can Arc. OpenLayers also has WFS rendering capabilites for a browser-based solution. At the lower level, GDAL can be used to convert the data from WFS to any vector format OGR supports.

If you want editing capabilities, both GeoServer and TinyOWS support WFS-T, enabling your users to upload their analyses back to your server.

Creating your own API really defeats the purpose of having these standards in the first place, unless you're incredibly specialised and you have specific requirements such as performance, and er... that's about all I can think of. Going this route, without a reasonable amount of resources is a fraught - although not impossible - task.