API solutions can facilitate the interconnection of Commonwealth entity, supplier, and partner functionality needed by government to manage internal and external engagements with stakeholders. Internal interoperability via API functionality can increase productivity, efficiency, accuracy, and visibility, and enhance management reporting. External interoperability can provide access to government data and should be governed under a fair use policy.
As identified on api.gov.au, APIs will generally fall into one of the following categories:
- System Level APIs: These are low-level APIs that are exposed directly by an application.
- Process Level APIs: These are APIs composed of other System APIs through orchestration and choreography.
- Experience Level APIs: These are APIs intended to ease the adoption of API integration between an organisation and its external consumers.
APIs may also be grouped as private, partner or public. Private APIs being utilised to facilitate internal system to system connection, Partner APIs being used to connect entity business partners to the relevant systems needed for government service provision, and Public APIs being used to connect external parties to government systems and data.
Understand the evolving API technology environment
Recent shifts in API architecture and design have included the evolution of API gateways from proprietary, supplier owned and managed interfaces to open-sourced alternatives offered at little or no cost. These technology offerings reduce implementation cost and provide for greater flexibility in interconnecting a breadth of other APIs and systems.
Different standards exist for APIs, and can be considered as retired, core, and emerging. The api.gov.au API design standard focuses on REST (Representational State Transfer) as the basis for design, noting its “core” position as the de-facto mechanism of data representation and transfer to/and from systems on the internet. Older API types, such as SOAP, should not be implemented and if they are in use should be replaced and retired. REST APIs typically are not good for streaming data or for largely function-based APIs; emerging alternatives such as GraphQL may be considered for these purposes.
API design is evolving to incorporate the segmentation of API data functionality into either control streams or pure data, thus ensuring the optimisation of data flow through the API. The technology movement in both API domains provides an opportunity for Commonwealth entities to enhance interoperability, reduce implementation costs and optimise data transfer functionality. There is also a recent trend towards direct incorporation of Machine Learning and Large Language Model systems that will be inherently dependent on API connectivity.
When developing a solution, consideration should be given to these emerging trends, with APIs implemented that are suited to the modern digital landscape.
Develop a comprehensive understanding of non-functional requirements and considerations
There are specific non-functional needs that require upfront consideration, including for legislative reasons. These needs may include, but are not limited to:
- auditability requirements of cases processes and/or outcomes
- privacy requirements of individuals, organisations, processes, or intellectual property
- security needs, particularly if the system contains sensitive or personally identifying data or is otherwise likely a target for threat actors
- availability/redundancy, especially in the case of systems supporting round-the-clock needs such as medical or emergency service activities.
Utilise api.gov.au as a central resource
api.gov.au was developed as a cross-government platform to provide guidance on API development requirements and to serve as a repository for the storage and distribution of Commonwealth entity-developed APIs. The broad goals of this national API design standard are to:
- create a technical API design standard to be used across the WofG for cross-jurisdictional data sharing
- improve overall quality of the APIs being shared, as well as the literacy around APIs and integrations
- build a cross-jurisdictional working group of API experts who can continue to foster and champion the standard across the Whole of Government (WofG).
The site provides additional background context on the development of the National API Design Standards (NAPIDS), including reasoning regarding selection of HTTP REST as the design standard for inter-government API development. The site provides templates that can be used to build standardised APIs, guidance on developing support materials, naming conventions, version control, and security requirements.
Utilising the API classification categories on the api.gov.au site:
- If your API is considered a System Level API, and is custom developed, it is recommended that you use the design standard as this will assist in developing Process or Experience Level APIs if they are required in future.
- If your API is a Process Level API you should apply the design standard, as often a process level API will be tailored for re-usability.
- If your API is an Experience Level API then the design standard must be applied.
The design standard does not apply to third-party system level APIs such as those available as ‘out-of-the-box’ or as part of SaaS platform, e.g. Salesforce APIs or ArcGIS APIs. However, the standard may apply if you were looking to re-expose these APIs as experience Level APIs for wider consumption.
In addition to setting standards and providing development assistance, the site functions as a GitHub repository. Entities can upload their APIs for utilisation by developers and other key stakeholders.
Adhere to reuse principles
Before an entity procures a system or reviews existing systems, it should consider its use case-specific functional and non-functional information asset requirements, including volume and nature of data, information and records, broader system purpose, performance matters, and privacy/sensitivity concerns.
Many instances of API solutions exist across government, one or more of which may be suitable for reuse through new instances of inflight API development or leveraging of existing API designs. These designs may be discovered through the AGA website, on api.gov.au, through direct contact with entities with comparable use cases, or via existing WofG procurement arrangements.
Reuse content on the AGA provides information for entities on reuse.
Lower development and maintenance complexity of API Solutions
API solutions can be implemented using a low-code / no-code development approach that utilises human-centred functionality to rapidly define, test, integrate, and present complex processes and rulesets in a modular and repeatable manner with minimal use of programming languages and an abstraction from the code itself.
Contemporary API solutions adopting a low-code / no-code approach can benefit from the removal of layers between an analyst’s expertise and the materialised solution. Direct engagement between the analyst and the platform can assist with optimising the end-to-end process or better integrating the needs of a stakeholder. Benefits of this approach include rapid development, a better-understood and more refined business process and enhanced stakeholder satisfaction.
In determining a development direction, entities should ensure that their selected solution is supportable, affordable, secure, and fit-for-purpose. Consider the suitability of low-code / no-code development paths prior to the use of more contemporary API development approaches.
Determine an appropriate API release, fair use, and distribution strategy
Commonwealth entities have invested in the substantial development of system APIs. Some of these may be used internally as patterns, supplied to other entities for systems interconnection or released externally for third party interface. API owners have a discretion as to how, and to whom, they release APIs that have been developed within each entity. All entities are encouraged to ensure a transparent approach to the availability for release of APIs, expectations around fair and reasonable use of the API and access to all associated data, and clear guidance on how they may be made available, including any supply costs.
Ensure the sustainability of API solutions
Entities should ensure that their selected solution is supportable, affordable, secure, and fit-for-purpose. This includes checking the contractual arrangements, Memorandum of Understanding currency, and AGA design state. The variance in API requirements across government inhibits an ability to pursue a single, centralised solution, or a universally applicable pattern. Unique API needs will dictate solution selection, design, and implementation.