Flexible frontend prefix matching without using 'matching order' field?

[brylie]

We allow end-users, of the Apinf platform, to add API Umbrella API backends, including defining a custom frontend prefix. This has led to some problems, such as the following frontend prefixes resolving to the wrong API Backend:

Intended:

• /music - initial frontend prefix added by user
  • Intended -> resolves to 'Music API: root'
  • Actual: works as expected
• /music/alternative/ - second frontend prefix added by user
  • Intended -> resolves to 'Music API: Alternative
  • Actual: respoves to 'Music API: root'

We are noticing that API Umbrella uses a global matching order field to mitigate this issue. However, in our current UI, a global 'matching order' might not make sense to a user who has just added one or more APIs, but who may not be responsible for the remaining APIs.

What are some ideas as to how we might allow end-users to add APIs, so that calls resolve in an intuitive/expected way?

[GUI]

Hm, I thought we had some existing discussion threads around some alternatives to our current "matching order" approach, but I can't find them, so maybe those didn't happen here (the closest is https://github.com/18F/api.data.gov/issues/186, which discusses the need to warn admins about conflicts, but not about different approaches).

In any case, one potential alternative I've discussed in the past is to always give precedence to more specific prefixes based on length. I might be over-simplfying this now, but I think the basic approach would be to sort all the prefixes by total string length (in descending order), and then use that as the matching order. That should ensure that more specific URL prefixes are always matched ahead of more general prefixes (since /music/alternative/ is longer in length than /music, the longer one would always be matched first).

There might be edge-cases I'm not thinking about right now, but I do think something like this would be a lot more intuitive, and it would eliminate the need for explicit matching orders and conflict detection.

A few more things to consider if we make this change:

• Are there any legitimate use-cases for forcing broader prefixes to match before more specific prefixes? I can't really think of any, since it always seem accidental in our current system, but it would be good to consider other uses. Theoretically, you could use it to hide a bunch of more specific API backends (maybe temporarily), but I'm not sure anybody's ever used it for that.
• How does this impact admin permissions based on path prefixes? I don't think it does, but just something to consider.
• If we made this change, how would we handle API Umbrella upgrades? There would probably be a need to detect any matching orders that would change by upgrading to this new matching approach, and warn people about that before upgrading (since it's possible you might currently have setups that aren't being matched, but would suddenly start matching after upgrading).
• Internally, we really have 2 matching orders--first on the API Backends, and then second on the prefixes within each backend. For example, API Backend A could have prefixes of /music and /movies/comedies and API Backend B could have prefixes of /music/alternative and /movies. To prevent fighting between API backend ordering and prefix ordering, I think we might need to flatten all of the prefixes out (ignoring what backend they belong to) for sorting and matching purposes.

[brylie]

cc: @bajiat @marla-singer

[brylie]

@GUI, we realize that this change would ideally be made at the Proxy layer, hence this issue. How can we support this work?