Hypertext Application Language

Description

Hypertext Application Language (HAL) is a simple, lightweight media type (application/hal+json or application/hal+xml) designed for representing resources and their relationships in hypermedia-driven RESTful APIs. It structures API responses to include not only data but also hyperlinks that indicate possible actions and relationships to other resources, adhering to the HATEOAS (Hypermedia as the Engine of Application State) constraint. This enables clients to dynamically discover and navigate APIs without prior knowledge of URI structures, promoting loose coupling between clients and servers. In 3GPP, HAL is adopted within service-based architectures, particularly for interfaces between Network Functions (NFs) in the 5G Core, to facilitate flexible and scalable communication.

The HAL format organizes resources into two main components: the resource state (data properties) and embedded resources (sub-resources included within the response). Each resource contains a '_links' object with hyperlinks keyed by relation types (e.g., 'self', 'next', 'related'), which define navigational paths. For example, a network function instance resource might include links to its associated services or management endpoints. This link-centric approach allows clients to traverse the API by following relations, reducing hardcoded dependencies and enabling API evolution without breaking clients. HAL also supports curies (compact URIs) for defining custom link relations, enhancing readability and standardization.

In 3GPP specifications, HAL is utilized in HTTP-based service-based interfaces (SBIs) defined for the 5G Core Network, such as those between the Access and Mobility Management Function (AMF) and Session Management Function (SMF). It works by serializing resource representations in JSON or XML format, with predefined schemas for network function discovery, registration, and service consumption. The protocol leverages standard HTTP methods (GET, POST, PUT, DELETE) and status codes, with HAL providing the structural consistency for responses. This enables automated service interaction, dynamic load balancing, and fault tolerance, as clients can discover alternative instances via links. The use of HAL aligns with cloud-native principles, supporting microservices architectures and continuous deployment in telecom networks.

Purpose & Motivation

HAL was introduced in 3GPP to address the need for standardized, hypermedia-driven communication in service-based architectures, particularly with the transition to 5G. Prior approaches, such as proprietary APIs or non-hypermedia REST, led to tight coupling between network functions, making systems brittle and difficult to evolve. HAL solves this by embedding discoverability into API responses, allowing clients to adapt to changes dynamically and reducing integration complexity.

The motivation for adopting HAL stems from the shift towards cloud-native and microservices-based core networks, where network functions are decoupled and deployed independently. Traditional telecom interfaces were often static and point-to-point, hindering scalability and agility. HAL enables a more flexible interaction model, where services can be discovered and consumed on-demand, supporting automation, orchestration, and network slicing. This is critical for 5G's demands on low latency, high reliability, and service diversity.

Historically, API design in telecom relied on protocol-specific methods (e.g., Diameter) with fixed message flows. HAL provides a web-friendly, RESTful alternative that aligns with IT industry practices, facilitating integration with cloud platforms and third-party services. It addresses limitations like versioning issues and client updates by using hyperlinks as the primary means of navigation, ensuring backward compatibility and future-proofing network interfaces. This enhances interoperability and accelerates innovation in network service deployment.

Key Features

• Standardized media type (application/hal+json/xml) for resource representation
• Embedded hyperlinks in '_links' object for API discoverability and HATEOAS compliance
• Support for embedded resources to include related sub-resources within responses
• Use of relation types (e.g., self, next, curies) to define navigational semantics
• Integration with HTTP-based service-based interfaces in 3GPP 5G Core networks
• Enables loose coupling between clients and servers, facilitating dynamic API evolution

Evolution Across Releases

Defining Specifications