When configuring APIs to be listed in the Portal Catalog, today the portal is providing support to APIs described using OpenAPI spec only (either subscribable or non-subscribable). This is, the API spec should explicitly declare paths.
It would be great if the portal could provide support for non-path oriented APIs in the Catalog. This is auto-discoverable, RMM-L3 APIs implementing the HATEOAS design pattern. This way, the portal UI could render an interactive, dynamic visual representation (a la Swagger UI or HAL Browser) for this type of APIs based on the operations and properties discovered dynamically.
When configuring APIs to be listed in the Portal Catalog, today the portal is providing support to APIs described using OpenAPI spec only (either subscribable or non-subscribable). This is, the API spec should explicitly declare paths.
It would be great if the portal could provide support for non-path oriented APIs in the Catalog. This is auto-discoverable, RMM-L3 APIs implementing the HATEOAS design pattern. This way, the portal UI could render an interactive, dynamic visual representation (a la Swagger UI or HAL Browser) for this type of APIs based on the operations and properties discovered dynamically.