Representational State Transfer

Description

Representational State Transfer (REST) is an architectural style, not a protocol itself, that guides the design of web services. It was formally adopted by 3GPP starting in Release 12 for defining Application Programming Interfaces (APIs), particularly for northbound interfaces (NBIs) and later for service-based interfaces within the 5G Core network. RESTful APIs in 3GPP are typically implemented using HTTP/1.1 or HTTP/2 with JSON or XML payloads, providing a standardized way for external applications (Application Functions, AFs) or internal Network Functions (NFs) to interact with the telecom network.

In the REST architectural style, everything is modeled as a resource, which is any information that can be named (e.g., a subscriber's session, a policy rule, a network slice instance). Each resource is uniquely identifiable via a Uniform Resource Identifier (URI). Clients interact with these resources using a uniform set of stateless operations, primarily the standard HTTP methods: GET to retrieve a resource representation, POST to create a new resource, PUT to update or replace a resource, DELETE to remove a resource, and PATCH for partial updates. The representation of a resource (e.g., in JSON format) contains its state or attributes. The server's responses are also stateless and can include hypermedia links (HATEOAS principle) to indicate possible next actions or related resources, though this is variably implemented in 3GPP specs.

Within the 3GPP architecture, RESTful principles are applied in several key areas. The Service Capability Exposure Function (SCEF) in 4G and the Network Exposure Function (NEF) in 5G provide RESTful northbound APIs to securely expose network capabilities and information to authorized third-party applications. Furthermore, the 5G Core network architecture is built around a Service-Based Architecture (SBA), where core Network Functions (like AMF, SMF, PCF) communicate with each other using service-based interfaces. These interfaces are often specified as RESTful APIs with HTTP/2 transport, allowing for flexible, scalable, and discoverable interactions between NFs. This contrasts with earlier point-to-point protocol-based interfaces (like Diameter), offering advantages in development simplicity, tooling support, and cloud-native alignment.

Purpose & Motivation

3GPP adopted REST to address the need for more open, flexible, and developer-friendly interfaces for interacting with telecom networks. Traditional telecom interfaces were based on complex, binary protocols (like MAP, Diameter) that were difficult for web and IT developers to use, hindering innovation and service creation. The rise of cloud computing and web services demanded a shift towards IT-friendly technologies.

The motivation for REST in 3GPP was multi-faceted. It aimed to simplify the integration of third-party applications (e.g., from IoT service providers, enterprise customers) with network capabilities through standardized HTTP-based APIs. This exposure drives new revenue streams. Internally, for the 5G SBA, RESTful interfaces enable a more decoupled, scalable, and agile core network where functions can be developed, deployed, and scaled independently, aligning with cloud-native and microservices principles. REST solves the problems of protocol complexity, vendor lock-in, and slow service deployment by leveraging widely understood web standards, vast tooling ecosystems, and enabling faster development cycles for both network operators and application developers.

Key Features

• Resource-oriented architecture where network entities are modeled as resources
• Uniform interface using standard HTTP methods (GET, POST, PUT, DELETE, PATCH)
• Stateless client-server interactions for scalability
• Resources identified and addressed via URIs
• Data exchanged in standard formats like JSON or XML
• Leverages ubiquitous web protocols (HTTP/TLS) for transport

Evolution Across Releases

Defining Specifications