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.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (44 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-12, normative work from Rel-15.
In Release 15, the REST function was enhanced with new JSON structures for query parameters, the formalization of HTTP POST for creating resources in the Npcf_SMPolicyControl and Npcf_AMPolicyControl services, and clarifications for the HTTP PATCH method. It also introduced specifications for the maximum HTTP payload size, HTTP scheme usage, and the IANA registration of the "3gppHal+json" media type. These updates provided a more structured and interoperable foundation for RESTful APIs within the 3GPP architecture.
- JSON Structures in Query Parameters TS 29.501CR0006
- Using HTTP POST to create resources for the Npcf_SMPolicyControl Service. TS 29.890CR0003
- Using HTTP POST to create resources for the Npcf_AMPolicyControl Service. TS 29.890CR0005
- Maximum HTTP payload size TS 29.501CR0041
- HTTP Scheme TS 29.501CR0042
- IANA registration of "3gppHal+json" media type TS 29.501CR0048
+ 1 more changes
In Release 16, the REST function was enhanced with specific updates including defining a maximum JSON payload size and establishing procedures for handling JSON Arrays. Furthermore, corrections and a finalized definition were provided for the REST Service Specification template. These refinements aimed to improve interoperability and clarify implementation details for service-based interfaces.
In Release 17, the REST function was enhanced with support for the HTTP PATCH method using "JSON Patch" and "JSON Merge Patch" encodings for updating resources, specifically for NIDD DL Data transfer. The release also introduced clarifications and corrections for handling HTTP custom headers in Northbound APIs, defined the HTTP "406 Not Acceptable" response, and refined the use of JSON Patch operations like the "test" operation and the conditions for adding members. Additionally, updates were made to HTTP Digest Access Authentication and references to the HTTP/1.1 protocol.
- Update of HTTP Digest Access Authentication TS 29.116CR0053
- Add the support for PATCH method for the update of a NIDD DL Data transfer resource TS 29.122CR0547
- Description of JSON body with "JSON Patch" encoding of changes TS 29.122CR0556
- Reference update for HTTP/1.1 protocol TS 29.201CR0049
- Correcting "JSON Patch" encoding of changes TS 29.122CR0497
- Corrections to HTTP custom headers handling for Northbound APIs TS 29.222CR0165
+ 12 more changes
In Release 18, the REST function was updated by uplifting the foundational HTTP specifications to align with modern IETF RFCs 9110, 9111, 9112, and 9113, and by adding explicit support for HTTP Multipart messages within PATCH requests. The release also included the documentation of 3GPP Custom HTTP Headers and clarified the usage of the 3GPP JSON Patch format. Furthermore, corrections were made to references for HTTP error status codes and their Northbound Interface (NBI) usages.
- Documentation of 3GPP Custom HTTP Headers TS 29.501CR0143
- Transferring the NSCE_NetworkSliceAdaptation API to TS 29.435 TS 29.549CR0220
- Updating the obsoleted IETF HTTP RFCs TS 29.122CR0757
- HTTP RFC uplifting TS 29.222CR0320
- HTTP Multipart message support in PATCH Request TS 29.501CR0155
- HTTP RFCs obsoleted by IETF RFC 9110 and 9113 TS 29.501CR0162
+ 3 more changes
In Release 19, the REST function introduced an expedited transfer indication from the AF to the NEF and clarified the mapping of active-inactive API states to management domain solutions. It also included updates for formatting JSON objects in query parameters, corrected the Naf_Inference API's attribute name and HTTP status codes, and aligned with the latest IETF HTTP RFC. Furthermore, it fixed an incorrect HTTP method reference for a mandatory error status code.
- Formatting of JSON objects and arrays of JSON objects in query parameters TS 29.122CR0890
- Providing Expedited Transfer indication from AF to NEF TS 29.122CR0941
- On mapping of active-inactive API states to SA5 solutions and aligning Service API Information descriptions TS 23.222CR0264
- Update of the template for the HTTP RFC obsoleted by IETF RFC 9113 TS 29.501CR0161
- Corrections on the attribute name and HTTP status codes for Naf_Inference API TS 29.530CR0006
- Incorrect HTTP method reference for mandatory HTTP error status code TS 29.549CR0424
Explore further
Broader topics and technologies where REST plays a role.
Defining Specifications
3GPP specifications that define or reference REST, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.222 vj80 | Common API Framework for 3GPP Northbound APIs | Rel-19 |
| TS 23.701 vc00 | WebRTC Access to IMS Architecture Study | Rel-12 |
| TS 23.722 vf10 | Common API Framework (CAPIF) for 3GPP Northbound APIs | Rel-15 |
| TS 28.890 vg00 | ONAP-3GPP 5G Management Compatibility Study | Rel-16 |
| TS 29.116 vj00 | REST-based protocol for xMB reference point | Rel-19 |
| TS 29.122 vj40 | T8 Reference Point for Northbound APIs | Rel-19 |
| TS 29.201 vj00 | RESTful Rx Interface for AF-PC Communication | Rel-19 |
| TS 29.222 vj40 | Common API Framework (CAPIF) for 3GPP Northbound APIs | Rel-19 |
| TS 29.501 vj40 | 5GC SBI API Design Principles & Guidelines | Rel-19 |
| TS 29.522 vj40 | 5G NEF Northbound APIs Stage 3 | Rel-19 |
| TS 29.530 vj00 | AF AI/ML Services Stage 3 Protocol | Rel-19 |
| TS 29.549 vj40 | SEAL API Specification for Vertical Applications | Rel-19 |
| TS 29.817 vc10 | Study on XML-based Rx interface for PCC | Rel-12 |
| TS 29.890 vg00 | CT3 5G System Technical Report | Rel-16 |
| TS 29.891 vg00 | CT4 Aspects of 5G System Phase 1 | Rel-16 |
| TS 32.158 vk00 | Management and Orchestration REST Solution Sets | Rel-20 |
| TS 32.856 vf00 | Energy Efficiency Assessment for RAN OAM | Rel-15 |
| TS 32.866 vf00 | REST, HTTP, JSON for Management Interfaces | Rel-15 |
| TR 33.938 vj10 | 3GPP Cryptographic Inventory for 5G | Rel-19 |