User have to create totally unique proxy base path

[marla-singer]

Now we have the rule that user must create the unique proxy base path. But we need to limit it more. Don't let user create the proxy base path if the first section of this path has is the part of other API

On local, I have three different APIs with the next settings. Bring to your notice that APIs have the different URL.

Found &expected

1. When I call https://nightly.apinf.io:3002/alternative/
   it redirects to https://music.yandex.ru/genre/alternative/ that's correct
2. When I call https://nightly.apinf.io:3002/alternative/artists/
   it redirects to https://music.yandex.ru/genre/alternative/artists/ that's wrong.
   Expected: http://petstore.swagger.io/test-elastic/
3. When I call https://nightly.apinf.io:3002/alternative/rock/
   it redirects to https://music.yandex.ru/genre/alternative/rock/ that's wrong.
   Expected: https://learn.javascript.ru/courses/nodejs

[brylie]

We are not committing to resolve this issue right away, but want to get a better understanding of the underlying parts. I have self-assigned and will look for upstream issues or discussions that might give us better understanding.

[brylie]

This seems related to the API Umbrella internal matching order field:

The matching order field tells API Umbrella in which order to route requests. API Backends with lower matching order value will be routed before higher level routes, when their frontend prefix matches, even when a higher matching order route might have a more accurate frontend prefix.

The reason for a matching order may be so the proxy does not have to parse the entire route prefix map each time it resolves a request.

[brylie]

In the spirit of this issue title, we might consider 'solving' this challenge by allowing multiple, explicit frontent prefixes per Proxy Backend. This aligns with the design of API Umbrella:

Then we can change our code to not use wildcard queries for getting/deleting analytics data, rather relying on the explicit frontend prefix.

[brylie]

Caveat emptor: this would require that API managers explicitly define every desired frontend prefix, rather than allowing for the 'catch all' prefixing that API Umbrella allows.

Currently, we require a new Proxy Backend to be created per frontend prefix.

[brylie]

Opened an upstream support request: NREL/api-umbrella#342

[bajiat]

@brylie We would need to unblock this issue. Can you get some advice from our developers?

[bajiat]

This is becoming even more urgent because of monetization and new dashboard. Let's resolve this during sprint 51.

[bajiat]

@brylie Please invite @matleppa, @marla-singer and @phanimahesh for a meeting to discuss both proxies and our domain model. Should happen 25 - 29 September

[brylie]

Invite sent for next Tuesday (2017-09-26).

[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]

I have summarized our discussion in the above comment, and will need to hand this task off to another champion.

[preriasusi]

#2319