...
Component for managing high-level APIs exposing the business logic of ONAP. Handles API management including the API Lifecycle, API Monitoring, API Security and Policy Control, API Transaction Logging, API Abstraction, and Transformation. Currently, there is a module in the MSB project with name Internal/External API Gateway. There is also an External API project. with the responsibility to integrate ONAP with OSS/BSS Solutions through TMF APIs. The proposed functionality should not be confused with what MSB or Ext-API is providing as of today and suggested to check the comparison below with Ext-API and MSB.
...
ONAP today has many components/projects and many APIs exposing functional capability of components. 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 component specific management/functional interfaces). Most of the times, such low-level APIs are very complex to manage and consumer (such as other components in ONAP, external applications, use case specific applications etc. ) 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. This often leads to the tight dependency between components and additional overhead for project teams. 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 need for such a facade layer has been discussed many times in the past in relation to the Modularity and also to make ONAP production ready/standard compliant etc. The API GW Project is proposed to address the following problem statements
...
Plan to develop Project PoC using the Gravitee API Gateway (https://gravitee.io/) Solution which is cloud-native, developer-friendly and features rich. However, we are also open for adapting other API GW solutions such as Kong or Gloo. Kong (link) is based on nginx and Nginx & OpenResty and have similar capabilities like Gravitee but requires the extension/plugins to be written in unpopular Lua script. Gloo is , additionally, it has limited reusable libraries to be used for developing plugins. Gloo (https://github.com/solo-io/gloo) is a project endorsed by CNCF and has a dependency on Envoy proxy, so can be considered when ONAP migrates to a service mesh based microservice communication model. Following is a high-level comparison (Note: our current subjective view based on the scope defined above) of different API GW solutions that we have evaluated. Inputs/suggestions are welcome from community members on other alternate open source solutions that we can leverage with friendly licensing terms.
Note on S3P :
- Scalability: Depends on the particular open source solution being selected - Majority of the open source API GW solutions support distributed scaling.
- Security: To be discussed with the Security Subcommittee - API GW inherently supports rich security management features - OAUTH2.0, Open ID Connect, Certificate management etc.
- Stability: All the proposed features are from mature API GW open source solutions which are in the production environment. Guidance from Architecture team on specific areas awaited.
- Performance: For API GW two aspects of performance is critical - Latency and Num of Requests per Second. Latency depends on the complexity of API and associated nested operations that need to be carried out for a particular API. The number of requests handled by API GW depends on the scalability features provided by the API GW. Performance benchmark can be carried out based on the requirements set by the S3P team or specific use cases.
...