Resource routing based on source/host system

by schervinskis   Last Updated January 26, 2018 06:05 AM

My organization is moving to a REST architecture and I have a small problem to solve.

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


Instance Resource URI


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 which admin system the resource is hosted in. 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 convienence service that will lookup the admin system and based on results route to appropriate data layer. This is a lot of Extra DB traffic.

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. Using the above routing logic, if we add a third admin system (business looking at 3rd party distribution options; hosted on and off prem), 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, is it a best practice? What are some best practices to solve for this? I’m new to REST design patterns and with my limited experience I proposed the solution below but it wasn’t received well:

Instance Resource URI


I thought by adding the admin system as a path parameter in the URI, 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. Wouldn’t this work? TIA

Related Questions

Pattern for endpoint that routes requests?

Updated December 10, 2016 08:02 AM