Layer7 API Management

Hi , 

We have to make call from one API to Other API with in the CA API Gateway. As of now we are using the URL as below in the routing assertion.

Routing URL :  https://localhost:8443/students/*/profile 

But our concern is that do we need the URL to be HTTPS, since it is a internal call. Is there any better way for internal routings?

Please let us know if there is any recommended approach. 

If possible I would recommend to avoid the routing all together and take your policy logic and covert it to a policy fragment or Encapsulated Assertion that you can call. 

Hi Dustin,

Thanks!

Using Encapsulated Assertion/Policy Fragment is one of the approach. But, We already have an API which does the required job. We are thinking to re-use the same instead of recreating the same logic with in policy fragment/encapsulated assertion.

Is there any other approach where i can route/refer to a existing service/API.

If it's a service on the gateway, it would be very easy to change the content of the service into a policy fragment and then re-use it in the new service without affecting the existing service. Follow the link on Policy Fragments which Dustin posted.

If for some reason you still want/need to route to the existing service, you could use the approach you already posted. Since it's localhost both http and https should be fine in my opinion.

For sure, I mean you can route to anything you want. The Gateway is powerful that way. :-) But the trouble comes with trying to route back to the original policy if that's needed, without affecting the other services which also use that policy/API that you said already exists. I don't think going down that route would be a good solution, as it would likely just introduce other complexities.

For your use-case, I strongly encourage the use of encapsulated assertions or policy fragments (probably policy fragments in this case is more useful to you) as the solution. Not only will it make it easy to debug in the future if any bad things happen, but it turns this into a long-term reusable item which gives it far more usability. Ultimately, if you already have a service/API that you need that now is needed by more than one service, then it means it should be a policy fragment as that is the exact use-case it was created for. So in that case, you should actually be turning your existing one into a policy fragment rather than feeling the need to duplicate it.

With that said though, if you want to take the "safe" route where you're not interfering with what's already there (in case this is why you may be hesitant to take this approach), you can always leave what you have and just duplicate the service you have now that you want to route to and then turn THAT one into a policy fragment, so that you're not interfering with any other operations. From there, you can then slowly migrate others to use the new policy fragment if it makes sense for your environment at that time and then finally remove the other one that you're wanting right now to route to.

I hope the above paints a bit of a better picture for you as to why everyone on here is so far recommending policy fragments. It truly is the best option in your case, based on what you've expressed so far detail-wise. Anything else will just lead to further complications down the road whenever troubleshooting is needed, not to mention possible performance degradation. I say performance degradation because if you go the routing path, then you're adding the extra overhead of a route when it wouldn't even be part of the equation if you had it as part of a policy fragment instead, so you immediately save that second or so from the routing part in comparison, which ultimately leads to performance improvements using a policy fragment.