Page History

...

ONAP today has many components/projects and many APIs exposing functional capability of components. However, there There are dedicated components which manage API transformation between internal and external systems - such as Ext-API, Multi-Cloud, SDNC/App-C etc. There are also projects which compose functionality and expose low-level APIs (which are focused on exposing interfaces). Most of the times, such low-level APIs are very complex to manage and consumer needs to be aware of very minute details (version, certificate, authentication, the right entity to be operated on, etc) of the provider to use the APIs in the right sequence and with the right information. There is no logical layer which consolidates these APIs and exposes a façade that is consumer friendly and hides many complexities associated with component level functional APIs. The API GW Project is proposed to address the following problem statements

...

Currently, there is no proposal to replace any of the existing components in ONAP. Some of the redundant functionality that exists between API GW and ONAP Components such as Ext-API and MSB can be managed through collaboration and mutual agreement. API GW can also potentially be a subproject of either Ext-API or MSB to augment the missing capabilities in respective projects. Another potential option is to merge functionality in Ext-API, MSB, and API-GW to create a single API Management/Adaptation component.

Please note the comparison of API GW and existing ONAP projects like Ext-API and MSB below. The comparison also covers what additional capability API GW bring in to augment the existing functionality. As for this proposal, the directions provided by Architecture committee and TSC will be followed once the need for such functionality is agreed with all stakeholders. 

...

1. API LCM: Manage the lifecycle of API – Onboarding of APIs as swagger or equivalent templates, Design of APIs with context path and backend endpoints, Association of API with required plugins to control runtime behavior, Activation or Deactivation of API, Management of Security aspects of the API
2. API Market Place, API Catalog Management: Provide a consumer-friendly and developer friendly API Management interface
3. Plan, Subscription Management: Ability to design API plans with different levels of control and provide management interface to subscribe to a particular API and approve the specific subscription.
4. Content/Payload based API routing: Currently MSB in ONAP Supports API routing based on Service endpoints, but not strictly based on the API payload or API headers. This is an augmented capability on top of MSB to be consumed by use case teams and projects so that any custom routing can be incorporated at the API layer rather than at the individual project level.
5. API Federation: Currently there is no consistent mechanism for federation between two ONAP instances at least at the API layer. This capability allows projects to leverage API GW as a gateway that manages communication between multiple instances of ONAP. Note that this capability only covers the
6. Consistent Security Management: Manage API security– primarily transactional security – Authentication, Authorization, Encryption. Authentication and Authorization is planned to be based on a pluggable model, i.e capability to integrate with the Auth Provider IDP within the operator premise or reuse capabilities provided by AAF. Encryptions is enabled through HTTPS based secure channel – for this API GW maintains a keystore and truststore (PKCS12 based stores)  with certificates signed by AAF CA/RAan authorized signing authority. API GW supports Authorization/Authentication based on OAuth 2.0, Open ID Connect, SCIM 2.0, etc.
7. Circuit Breaking, Timeout, Retries, and Rate Control: Capability to control the API consumption by tuning the APIs usage properties. These capabilities may be controlled on demand using the management APIs exposed by API GW.
8. Flexible Request and Response Transformation: Capability to transform the API payload (request or response) based on predefined transformation logic – The transformation logic can be implemented as plugin and can be configured at runtime using exposed properties. The transformation plugin may also support expression languages (such as JOLT) or script insertion to transform the request or response. Other transformation capabilities include header, URL transformation, XML/JSON payload transformation, Request Method transformation, Security mechanism transformation etc.
9. API Sharding (Targeted API Deployment) : Targeted deployment of APIs at distributed API GW Instances based on specific criteria – i.e geographic proximity, load etc.
10. Service Discovery: Discover the API endpoints (backend Service APIs) based on registry look up and load balance the request across discovered services.
11. Façade: Aggregate/Compose complex low-level APIs and expose simplified façade APIs associated with service endpoints
12. API Policy Enforcement: Define API control policies – security or run time behavior
13. Common look and feel and documentation: Ensure common look and feel, documentation for exposed ONAP APIs
14. API Metrics Collection, Analytics, Metering, Audit, Logging: Capability track all the API transactions and identify the usage pattern, traffic
15. Alerts: Enable API consumption specific alerts so that corrective actions can be carried out on-demand.
16. White Listing, Black Listing of APIs based on the Subscription profile, Policy
17. API Designer: a Designer tool to import swagger APIs, attach appropriate policies associated with API, commission and decommission APIs, manage subscriptions and plans

...

Supported Operators: Vodafone, Swisscom