Naming Conventions
URI Structure
APIs MUST follow the defined hierarchical structure:
https://azgw.api.ukhsa.gov.uk/namespace/product/v1/users/12345?sort=startDate
\____/ \___________________/ \______________________________/ \____________/
| | | |
scheme authority path parameters
- Scheme: MUST always be
https://
- Authority: Will be determined by the APIM platform
- Path: Will consist of components:
- Namespace: Predefined business area or capability
- Product: The business product name
- Version (v1): the major API version with ‘v’ prefix
- Collection (users): the REST collection
- Resource (12345): The REST resource identifier
Each resource MUST be uniquely identifiable by a Uniform Resource Identifier (URI).
APIs MUST use lowercase for the entire URI.
APIs SHOULD limit the level of nesting to avoid overly complex URIs. Typically, two to three levels are sufficient.
Namespaces
Namespaces and product names MUST be based on the Business Capability Model.
For example:
https://azgw.api.ukhsa.gov.uk/prevent/vaccine-management/v1/..
Resource Names
APIs MUST use lowercase plural nouns to represent collections (e.g., /orders, /customers, /products) not verbs.
Path Segments
APIs MUST use kebab-case for path segments.
Parameter Names
APIs MUST use lower camel case for query parameter names.
Terminology
APIs MUST use consistent names for query parameters having the same function across different endpoints.
Example:
Property Names
APIs MUST use lower camel case for properties.
Example:
Terminology
Use consistent terminology across the API and in documentation. For instance, if you use customer
in one part of your API, don’t switch to client
in another API if they represent the same concept.
Example query string:
Example request/response model:
Published: 15 January 2025
Last updated: 14 August 2025
Page Source