Design a solution for consistent, namespaced URL paths in Catalog, API Umbrella, and eMQ

[bajiat]

Problem

At the moment, Apinf UI allows the user to use any proxy backend path as long as it is unique. However, API Umbrella matches APIs for calls by the matching order field. As a result, calls maybe terminating in a way user is not expecting. As a worst case scenario, they ends up calling a completely different API.

See: https://github.com/apinf/docs/blob/master/docs/research/Namespace%20for%20frontend-prefix.md

Related to following issues: #2093, #2032

Possibly related to: #1400, #2279

Goal

Finding a user-friendly solution for front-end prefix that would prevent conflicts in API calls and in API analytics.

Related

• See https://github.com/NREL/api-umbrella/issues/342

[brylie]

Notes from our meeting with @bajiat, @matleppa, @Nazarah, and @phanimahesh:

Consistency across features

Wen resolving this issue, we want to be consistent across the followint APInf features:

• API Catalog namespaces
  • e.g. /user_or_organization_slug/api_slug/
• Proxies/brokers
  • API Umbrella frontend prefixes
  • eMQ topic prefixes
• Dashboards
  • API Umbrella dashboard
  • eMQ dashboard

Wireframes needed

Wireframes will be needed for at least:

• Add API user flow/screen(s)
• Add Proxy Backend user flow/screen(s)
• Namespaced API management screen
  • view of all managed APIs, allowing them to be reordered for proper request resolution

User flows

Hypothetical user flow for adding an API

• Ask whether it is a personal or organization API
  • only organization managers will be able to add APIs to their organization, otherwise the option will not be available

Hypothetical user flow for adding Proxy Backend

• While validating form input (specifically the frontend prefix), make sure prefix conforms to uniqueness criteria (to be determined)
• warn user about overlapping frontend prefixes
• help user to manage the matching order of APIs they manage
  • either personal or organization APIs
    • possibly grouped by personal or each organization which they manage
  • possibly with different groupings depending on related proxy

Desired flexibility

Things we would like to allow:

• nested frontend prefixes of arbitrary depth. E.g. where /hslis the namespace, we might see the following hierarchical paths:

  • /hsl/
  • /hsl/busses/
  • /hsl/busses/realtime/
  • /hsl/busses/schedules/
  • /hsl/transit/trains/
  • /hsl/trains/realtime/
  • /hsl/trains/schedules/
• users may manage APIs for several contexts:
  • personal APIs
  • organization APIs
  • APIs on multiple proxies
• users may even be part of multiple organizations

[brylie]

Renamed issue and copied discussion notes from #2093.

[ilarimikkonen]

needs analysis