Routing Logic/Design Patten In REST API where Multiple Admin Systems Exist

My organization is moving to a REST architecture and I have a small problem to solve. I'm sure it's been solved a million times so thanks in advance for sharing your experience.

I have two admin systems that host products/resources of the same type and so I use a common pattern of an aggregator collection resource with each element of the payload containing a HATEOS link to the instance resource from that element. Here is the URI pattern in the current design.

Collection Resource URI v1/line-of-business/product-line/business-process/product-resources

Instance Resource URI v1/line-of-business/product-line/business-process/product-resources/resource-uuid/product-resource

Using this URI pattern, the resource will make a call to a uuid Mgmt service to decrypt the resource id to use as a query parameter in the back end to build the resource object. The problem is, the instance resource API doesn’t have any context to know which admin system the resource is hosted on. A couple of other work streams made the following suggestions to resolve this issue and route the instance resource to the correct admin system:

1. query system A first and if the result is empty, then make a call to system B but we agree this is an bad practice that I don’t want to implement this as a strategic solution.

2. Create a convenience service that will lookup the admin system and based on results route to appropriate data layer. This is a lot of Extra DB traffic.

3. one idea was to concatenate the admin system with the UUID and have some parsing logic on the service to know which admin system to point to. to me, that's bastardizing the UUID which is intended to obfuscate the resource id which is the key to my backend system and not be a catch all for meta data to control some switch logic. It also tightly couples us to that UUID mgmt backend. I think UUID should live in the source system.

FYI, system A will be retiring but not for a few years and we all know how those plans go. It could be around for many years when they start estimating the cost of the data conversion and retirement and further, our business is looking at going with some third party distribution models that could potentially introduce new backend admin systems that we'll have to code for. Using the above routing logic, if we add a third admin system, we’d have to modify our routing logic to check the new system as well.

I can’t find any examples of this problem but I know it’s been solved many times. Are the above lookup/routing solutions common? Even if the answer is "yes, they are common", does that make them best practice or utilization of good design principals? Anyone have any best practices they've executed to solve this issue? I’m new to REST design patterns and with my limited experience I proposed the solution below but it wasn’t received well. I proposed to add an admin system identifier as a path parameter in the URL. For example:

Instance Resource URI v1/line-of-business/product-line/business-process/product-resources/{admin-system}/{resource-uuid}/product-resource

I thought by adding the admin system as a path parameter in the URL, we don’t have to make any extra DB calls. The resource mediator can route to the appropriate data layer based on path parm. This also allows us to add new admin systems on the fly. After all, it is the "Unified Resource LOCATOR."

I know this would work but can anyone explain why this would be bad design or poke holes in it? Our clients don't need to know the admin system because we provide it in a HATEOS link from the collections resource. They always call the collections resource first using some header context to get the UUID of the resource they need. And these are all private APIs (internal to organization but exposed to other enterprise and customer facing applications).

sorry for the long explanation/question. Interested in discussing this if you need any more details.