Victoria’s API portal
Victoria’s API , currently in Beta release, has been designed so developers can connect their apps or websites with Victoria’s open datasets via APIs. The current catalogue includes APIs from DataVic, the EPA, important government dates, Museums Victoria collections, and Victorian Heritage. This represents the starting point for this exciting new development in Victorian Government APIs.
The focus on APIs is also in line with Australia’s Second Open Government National Action , which includes the commitment to: “improve the sharing, use and reuse of public-sector data”. APIs are a way to deliver on this commitment.
What are APIs?
API stands for ‘application programing interface’ and within the web development context it usually refers to a set of specifications for how web commands will ‘communicate’ with each other, such as HTTP requests and responses in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. The API is a structured way to represent data that an application has stored in its database. For example, a website page might request information from a customer resource (e.g. a road rule or a dataset) and return the results.
Why standardise APIs?
Governments across the world are trying to standardise and consolidate digital services. As more government services become digitised the opportunity to expose these services as APIs becomes greater, which lowers the barrier to industry and citizens accessing digital content and services. However this increases the need for handling and standardising common underlying problems and patterns related to hosting, security, interoperability, etc.
As a result, it’s becoming increasingly important for governments to standardise APIs to ensure optimal communication and interconnectivity between websites, databases and other software. Many governments have moved towards setting up their own API specifications, including Victoria.
API portals are also becoming increasingly important within government. For example, Singapore has a centralised API database called APEX (read OPSI case ) and the US has .
APIs at work
There are many examples from around the world, and within Australia, of how APIs are being used by governments, as well as many potential use cases.
In Iceland, the Icelandic Directorate of Health has set up a system where citizens can download their personal health data onto a device of their choice, and then share it with others if/when they want. This has been set up through a citizen-facing API. See the OPSI case for more information.
In another example, New Zealand is coding policy and law in a machine-readable format, using APIs. Work is still ongoing for this project, but initial pilot results have led New Zealand to pursue the ‘legislation as code’ model. See the OPSI Better Rules case for more information.
Closer to home, in Queensland the Department of Environment's State of the Environment Report uses a CKAN API to present data on its website.
Victoria’s Single Digital Presence is another great example of APIs in government. The Single Digital Presence platform currently uses APIs for its decoupled frontend, but there is also an opportunity to use those APIs in other applications.
An example for the potential of APIs is self-driving cars. If road rules are opened up as APIs, cars can use the relevant government rules in their programming, using the APIs to communicate with the corresponding government body.
API standardisation in Victoria
In March 2018 the Department of Premier and Cabinet’s Digital Engagement group formed the Whole of Victorian Government (WoVG) API Gateway team. The team was setup to support and promote the use of APIs, including creating API design standards and API training.
View Victoria’s API design (draft version)
What the API design standards cover
The Victorian API standards currently contains 14 major sections:
Getting Started: Building an —why they’re important for government, the API lifecycle, how and when to apply design standards, and why REST was chosen.
Interpreting These — defining the terminology used.
WoVG API — API documentation and development guidelines.
Naming — URL naming conventions, query parameter names, field names and link relation names.
API — versioning scheme (major, minor and patch), end-of-life policy and API deprecation.
API — request headers, HTTP request methods and request payload formats.
Query — pagination and filtering and sorting.
API — response headers, HTTP response codes and response payload.
Error — error response payload, input validation and error samples.
API — covering areas such as API design, authentication and authorisation, audit logs, content type validation and gateway security features.
— linked data, compliant API, link description object and link relation type.
Current status of Victoria’s API standard
The Victorian API design standard is currently in draft status. The standard leverages a lot from the general REST API specification, with the main difference being around the specific security that the API should follow.
Salsa Digital’s take
APIs are being used more and more in government settings and have the power to help consolidate government services. Like many areas at the moment, APIs are a hot topic in digital transformation in government and will continue to be so for some time. They also form a key part of Australia’s commitment around sharing, using and reusing government data, and are important to the open data and open government movements. It will be interesting to see how APIs are used in the future to deliver benefits to citizens — we look forward to covering some case studies in this digital transformation in government series.