Why does the public sector want to publish its services as APIs?
To help answer that question, we can start by remembering that ArcGIS is an API. ArcGIS is a set of open web services which deliver maps, data, visualisation and spatial analytics to anyone. Anywhere. On any device.
Most organisations using ArcGIS Online or ArcGIS Enterprise have no idea they already have a rich modern API on to their data and services. Many in the public sector have active Open Data programmes working out how to publish their Open Data (spatial and non-spatial) over an API – without being aware they are already doing it!
The ArcGIS API was published as an open standard several years ago. As a REST and JSON-based API will be familiar to developers and data scientists. It adheres to the Government’s recently published guidance on the development of APIs for public services. This guidance is worth a read if you’re even a little bit technical.
Back to the question of why….
Recently I walked down to a place called Freeth Mere with my family. This is a Site of Special Scientific Interest, about a mile from where I live on the Wiltshire/Gloucestershire border. It’s a great place to see water birds – Coot, Pochard, Grebe – but is designated an SSSI because of the stonewort which grows in the water.
Here is a picture of my daughter and me admiring the tranquillity and beauty of this special place. It looks like I’m taking a picture, but what I actually see through my phone is this.
That’s pretty clever – a bit of augmented reality showing me some extra information about where I am – some spatial data in my view. But this is not that clever by itself. There are plenty of apps around that allow me to load and process some spatial data and show a view similar to this. So the app is not the clever bit.
Here is the clever bit. The data being shown in my augmented reality app is live. It is not data published 6 months ago, copied into another database, sent to a third-party app developer and then packaged into a static application. It’s the same live data that other people can see in ArcGIS Online.
It’s also the same data that professional GIS users see in ArcGIS Pro. Live.
What does this mean? It means that when my data is edited, perhaps by a conservation officer in the field using Collector for ArcGIS or crowd-sourced in a public web app, the new data is instantly available in ArcGIS Pro, ArcGIS Online, and even in my augmented reality app. Live.
And because the ArcGIS API is an API built using open standards and is fully documented, the data is not stuck in a GIS. It’s available to anything that wants it. It’s the same data that developers of other applications see when using the API from their applications.
For example, I can use this API in the open source QGIS application. Live.
This is so important that I will repeat myself: this is not a copy of the data taken into a Shapefile and fiddled around with then loaded into another application. It’s the same data, with the same security permissions, the same attributes, accessed from the API over the web in exactly the same way as the ArcGIS apps access it. (As an aside, to see the data in QGIS I could have used the WFS endpoint in ArcGIS, but in this example I used the built-in ability of QGIS to read an ArcGIS Feature Service – the ArcGIS API).
Of course I can publish this data in an ArcGIS web application specially designed for public use, so it can be more easily discovered, viewed and downloaded by the public. Live.
Now I hope you can start to see how powerful an API is. I can distribute the same data to lots of different communities in different ways. And it doesn’t just stop at viewing data. I can also publish my own Geoprocessing services over the API, allowing simple or incredibly complex analysis to be available to anyone. Anywhere. On any device. And of course I can edit the data using the API. In fact, in my service, anyone can edit the data using the API, because I have deliberately left the endpoint of my service completely open. The ArcGIS API of course contains authentication and authorisation, which can be linked to existing authentication management systems such as SAML and Active Directory. If you are an existing ArcGIS user you will understand this authentication system as the named user model.
Since the data is editable through the API, we can do something even more powerful. With the ArcGIS API, data publishers can choose to lock their data down very tightly, or make it editable by anyone, or even editable by people authenticated with a simple social media login. Now we can move beyond open data provision and one-way policy communication from Government. Citizens can individually engage directly in policy initiatives and create the data themselves, with Government acting as both a supplier and a consumer of the data, as well as an enabler. You probably know this as crowd-sourcing, but it is much more powerful than the name suggests.
In my simple example above, you can imagine conservation-minded members of the public submitting the ecology observations themselves to my service. There are great, real examples of this going on in the public sector already, for example in the Greater London Authority’s workspaces initiative to drive economic growth – by connecting people looking for a space to work with those people who have more space than they need.
Now I hope we can understand why an API is really important. If the Government delivers just a web application, a set of users can access the data in just the way the Government has designed: the Government needs to provide all the tools to use the data. If instead the Government delivers an API, its partners and the public can collaborate using their own applications, processes and tools. They can view, edit and analyse live data in the way they need to, based on the security permissions applied. For example. think of the number of public- and private-sector organisations, and the level of public participation, involved in the planning and delivery of High Speed Two.
Design, development and documentation of a bespoke API for a digital service is expensive and time consuming, even with the wealth of tools available to help. And a bespoke API means that every user of your API is probably going to need to configure some software or write code in order to read and use your data. This is where ArcGIS is really amazing: your API is available on day one, from the moment of enabling your ArcGIS Online organisation or installing ArcGIS Enterprise. Whether you are just sharing Open Data, crowd-sourcing data from the public or securely collaborating across agencies on complex multi-dimensional projects, people already know how to use it.
Appendix – first steps to using the API
If you want to get metadata from the API about my service, you can hit the persistent URL:
https://services.arcgis.com/o2LSl4aYwDzAIuw9/arcgis/rest/services/SSSIFeatures/FeatureServer/0
The service in this example has junk data in it. But if you want to get the feature with the ID of 3, you can do it like this:
https://services.arcgis.com/o2LSl4aYwDzAIuw9/arcgis/rest/services/SSSIFeatures/FeatureServer/0/3
What if I want feature 3 and 6, but I want them in WGS84 instead of British National Grid? No problem:
https://services.arcgis.com/o2LSl4aYwDzAIuw9/arcgis/rest/services/SSSIFeatures/FeatureServer/0/query?where=&objectIds=3%2C6&outFields=*&outSR=4326
And in GeoJSON instead of HTML or Geoservices JSON? No problem:
https://services.arcgis.com/o2LSl4aYwDzAIuw9/arcgis/rest/services/SSSIFeatures/FeatureServer/0/query?where=&objectIds=3%2C6&outFields=*&outSR=4326&f=geojson
The API is fully documented online at developers.arcgis.com. Refer to the documentation for more details, for example how to make spatial queries on the data and how to edit it. Or email opendata@esriuk.com.
