An increasing number of services provide an HTTP-based REST API as their main interface to other network elements. The Rhino REST API Framework provide tools to allow Rhino developers to easily add support for REST APIs in their applications.
Objectives of the REST Demonstration
The focus of the Rhino REST API Framework Demonstration is to meet the following objectives:
-
Demonstrate how a REST API (generated with the REST RA framework) is used in a Rhino TAS based application
-
Demonstrate integration of REST APIs with Sentinel
-
Demonstrate how a Call Notification REST API can be used to influence call processing
The REST Demonstration emulates a real-world architecture with an application based on Sentinel-SIP that uses the prototype MetaSwitch Call Notification REST API during SIP call processing.
REST Demonstration Scenario (Real-World Architecture)
| Architecture | Description |
|---|---|
|
The MMTel-AS receives SIP triggers from the S-CSCF. The MMTel-AS, acting as an MSW-CN client, sends notification requests to the Business Logic node. The Business Logic node is an MSW-CN server that receives notifications from the MMTel-AS. The Business Logic node will return instructions in response to Call Direction requests that the MMTel-AS will follow in subsequent processing of SIP signaling. |
REST Demonstration Architecture that uses the Metaswitch Call Notification API
The following architecture for the REST Demonstration has been chosen because:
-
Sentinel-SIP implements the required SIP B2BUA behavior
-
Existing SIP features can be used
-
Demonstrates the integration of REST APIs with sentinel platforms
| REST Demonstration Architecture | Description |
|---|---|
|
A set of features and a session plan that uses sentinel-sip.
|
|
See Sentinel Overview and Concepts for an overview of the sentinel platform used in the REST Demonstration. See Sentinel Express for sentinel platform documentation. |
Rhino REST API Framework
Historically, applications running on Rhino TAS, including Sentinel VoLTE, have had to support these APIs by using the HTTP Resource Adaptor, and manually constructing the appropriate HTTP messages, which is time-consuming and prone to errors.
Alternatively, it is possible to write a custom Rhino resource adaptor (RA) that presents Rhino applications with a clean Java interface to a REST API. Writing a custom resource adaptor is a lot of work that must be repeated for each REST API that is to be supported. The result of this approach is a proliferation of RAs that are very similar, if each RA only supports one API.
The Rhino REST API Framework provides a better method for supporting REST APIs in Rhino by:
-
Providing a toolchain that can process a number of OpenAPI documents, and produce a fully functional REST Resource Adaptor supporting all of those APIs, ready for use in Rhino services.
-
Supporting OpenAPI v2 and OpenAPI v3 documents.
-
Providing a mechanism for supporting existing REST APIs that may not have an OpenAPI definition, such as OMA Call Notification.
-
Providing a mechanism for supporting REST APIs that use externally-defined types such as XML Schema.
|
|
See: Rhino REST API Framework for an overview of the Unified REST RA Framework. |
OpenAPI
The OpenAPI Specification has emerged as the industry standard for describing REST APIs, and this has enabled many tools for generating code and other resources. The problem of "how can my application talk to or implement this REST API" has largely been solved — tools such as openapi-generator can generate client and server code for many languages and frameworks, so getting up and running with a new REST API is a simpler task.
|
|
See: Introduction to REST APIs and OpenAPI for an overview of OpenAPI. |
