To call apigeex, is there any way I can call without passing environment group as host?

[amitkhosla]

Hi,

We are planning to use APIGEEX. We are planning to use multiple dns entries to point to same APIGEEX' environment group. 

Hence, we are looking to pass this dns entry and read in a policy to send to appropriate backend.

But as we need to call using the environment group url, so it becomes difficult to call APIGEEX in that case.

Is there any way, we can call APIGEEX directly without using the environment group url? Maybe pass this information in another header?

Thanks & Regards

Amit

[dchiesa1]

We are planning to use APIGEEX. We are planning to use multiple dns entries to point to same APIGEEX' environment group.

OK, sounds good.

Hence, we are looking to pass this dns entry and read in a policy to send to appropriate backend.

as I understand, you would like to perform routing on the inbound API request, based on the hostname that is used for that inbound API request. An inbound request with host1.apicompany.com will go to target1 (or backend1 if you like), and an inbound request with host2.apicompany.com will go to target2. Something like that. Is that right

But as we need to call using the environment group url, so it becomes difficult to call APIGEEX in that case.

Is there any way, we can call APIGEEX directly without using the environment group url? Maybe pass this information in another header?

To answer your question, no, you cannot call Apigee X without the environment group URL. There is an exception of course - an API proxy can "chain" to another API proxy using LocalTargetConnection.

But I don't understand "we need to call using the environment group url". Who is "we" in this case? I think there are three actors: a client, the Apigee API proxy, and the backend system.  The client app (actor #1) sends a request inbound to the Apigee X proxy (actor #2), using one of the hostnames in the environment group. At that point the API proxy can execute routing logic to choose the appropriate backend (actor #3) for the request. When the Apigee API proxy invokes the backend system, it does not use the environment group URL. It uses the URL for the backend system.

Surely I am misunderstanding something. Can you clarify?

[amitkhosla]

Thanks for quick reply!!

Clients calls using a URL like cleint1.apicompany.com/api1, client2.apicompany.com/api1 etc. We are planning to use client1/client2 as part of input url to resolve appropriate backend.

Ask is to call same proxy (/api1) (in same environment group) to be called via any of these URLS.

So, requirement is APIGEEX should be able to know the URL it is being called from.

Apologies for confusion.

Thanks & Regards

Amit

[dchiesa1]

The environment group mechanism within Apigee allows you to specify multiple hostnames .  So you can configure apihost1.apicompany.com and apihost2.apicompany.com as inbound hostnames. It would be your responsibility for configuring DNS A records for those hostnames. 

Then in the context of an API request, the API proxy can read/examine the HOST header (read context variable request.header.host) to find the hostname the client used to connect into the Apigee API proxy. 

I think it might be as simple as that. 

[amitkhosla]

Thanks a lot for your reply! This would have worked absolutely, but we are looking for many clients. I think the limits on APIGEE is only 85 environment groups per org. Thus, it will not fit for our application.

Is there any other way via which we can connect to APIGEEX with custom URLs?

Thanks & Regards

Amit

.

[dchiesa1]

we are looking for many clients. I think the limits on APIGEE is only 85 environment groups per org. Thus, it will not fit for our application.

The correct limit here should be the number of hostnames per environment group, not the number of environments per org. If you just add the hostnames to the env group as I said, then you'd have one hostname per "partner" or customer, in your single environment group. The limit there is 100, not 85. Consult the limits page for info.

Regardless, I understand that you mean to serve lots of clients. With that many clients, I would advise against giving each of them an independent DNS name. Specifically because you will run into problems of the sort you have described.

Just use one DNS name. Apigee can distinguish between clients by using the client ID. That is the intended purpose of the client ID.

[amitkhosla]

Thanks for the reply!!

Apologies for delayed response, was discussing same with product. Product team still feels we require clients to use different urls like client2.apicompany.com.

Is there any other alternative?

Thanks & Regards

Amit

[dchiesa1]

Product team still feels we require clients to use different urls like client2.apicompany.com. Is there any other alternative?

Maybe?

use the GCP External load balancer. Configure it with a wildcard certificate (*.mycompany.com or *.api.mycompany.com), and then specify a "Host rule" inside the Load balancer to "rewrite" the hostname to the authoritative hostname for Apigee-X , the one hostname that is present in the Environment group for your Apigee environment. I haven't tried this, and I don't know of any customers who have tried this. It's just an idea, but I think this should work.

The proxy running in the environment will receive the request, regardless which host is used to address it. One catch, though ... the proxy won't be able to "See" the original hostname included in the inbound request. The proxy will see the authoritative hostname.

If it's necessary for the proxy to "see" the original client-specific hostname, then ... you cannot do that, using only the External Load Balancer. The external LB cannot perform header injections as it rewrites a request. You would be able to solve that with your own managed instance group running something like nginx. Again, I haven't tried this, but it should be straightforward. Configure the nginx to (a) rewrite the host from the client-specific one into the single authoritative hostname, and also (b) inject the original client-specified hostname as an additional header in the request that is sent to Apigee X. Basically the data path would be: External LB -> nginx -> Apigee. If you like, your nginx could check the client-specified hostname against a valid list, and only if valid then "Rewrite" it to the Apigee-X -expected hostname if the client-specified hostname is valid. Or, you could have the validity check inside the Apigee proxy.

You didn't ask me, but ... This seems like a lot of work to accommodate client-specific hostnames. "Product team still feels..." That's sort of a weird thing to force on customers. It's a throwback to when there was a dedicated server for each client. Which, in the era of cloud, is unrealistic and costly. The named service is not dedicated to the client, it is client-agnostic. By "faking" client-specific hostnames you are trying to obscure that, but it seems like it's a lot of work for both you and the client/customer teams. Not sure what the benefit is. For sure there is a non-zero cost to design, configure, and operate those nginx servers to make sure they keep running.

If the only goal is "We are planning to use client1/client2 as part of input url to resolve appropriate backend." as you stated above, then there are MUCH better and easier ways of accomplishing that in Apigee . Notably - custom attributes on the client app. This screencast talks about the use of  custom attributes on an API Product... This is not exactly what I am suggesting for you, which is using custom attributes for each specific client.  But what I showed in the screencast would work the same way with client-scoped custom attributes. The attribute gets slurped into the request context automatically, when you validate request credentials (apikey or token).  You could then use the client-scoped attribute to route the request to a different backend, or inject a header into the backend identifying the client or partner for that backend. Much simpler.