B.3.10 URI structure and supported content formats

28.3063GPPControl and monitoring of Power, Energy and Environmental (PEE) parameters Integration Reference Point (IRP)Release 17Solution Set (SS) definitionsTS

This clause specifies the URI prefix and the supported formats applicable to the APIs defined in the present document.

All resource URIs of the APIs shall have the following prefix:

{apiRoot}/{apiName}/{apiVersion}/

where:

{apiRoot} indicates the scheme ("http" or "https"), the host name and optional port, and an optional prefix path.

{apiName} indicates the interface name in an abbreviated form. The {apiName} of each interface is defined in the clause specifying the corresponding interface.

{apiVersion} indicates the current version of the API and is defined in the clause specifying the corresponding interface.

For HTTP requests and responses that have a body, the content format JSON (see IETF RFC 7159 [9]) shall be supported. The JSON format shall be signalled by the content type "application/json".

All APIs shall support and use HTTP over TLS (also known as HTTPS) (see IETF RFC 2818 [10]). TLS version 1.2 as defined by IETF RFC 5246 [11] shall be supported.

NOTE 1: The HTTP protocol elements mentioned in the present document originate from the HTTP specification; HTTPS runs the HTTP protocol in a TLS layer. The present document therefore uses the statement above to mention "HTTP request", "HTTP header", etc., without explicitly calling out whether or not these are run over TLS.

NOTE 2: There are a number of best practices and guidelines how to configure and implement TLS 1.2 in a secure manner, as security threats evolve. A detailed specification of those is beyond the scope of the present document; the reader is referred to external documentation such as Annex E of 3GPP TS 33 310 [12].

All resource URIs of the API shall comply with the URI syntax as defined in IETF RFC 3986 [13]. An implementation that dynamically generates resource URI parts (path segments, query parameter values) shall ensure that these parts only use the character set that is allowed by IETF RFC 3986 [13] for these parts.

NOTE 3: This means that characters which are not part of this allowed set need to be escaped using percentencoding as defined by IETF RFC 3986 [13].