one target endpoint or 2 targets?

[#1]

Hi there,

Can you please explain me whether in the situation below I should use 2 different target endpoints or one common one?

My users can make these valid API calls:

http://api.domain.com/maps/copyright?key=myKey&{queryParams}

http://api.domain.com/maps/tile?key=myKey&{queryParams}

http://api.domain.com/maps/wmts?key=myKey&{queryParams}

I set up in the Maps api proxy several proxies with several base paths:

1. /maps/copyright goes to target endpoint Bk1: https://backendOne.domain.com/maps/copyright

2. /maps/tile goes to target endpoint Bk2: https://backendTwo.domain.com/maps/tile

3. /maps/wmts goes to target endpoint Bk3: https://backendTwo.domain.com/maps/wtms

Is the above setting correct or should I have one default proxy (/maps/ goes to default target https://backend.domain.com/maps) and all the other paths defined through conditional flows? Please advise which is the best solution and why.

Thank you a lot,

Emilia

[DChiesa]

I think I would probably use a single API proxy for all of those requests, since they all go to the same backend, and since all of those requests will be used together.

There are a few reasons to use multiple API proxies:

1. You have different security or authorization on the API proxies.
2. You would like to manage the lifecycle of the different API proxies independently.
3. The API proxies perform different actions, and are implemented by different people or different teams.
4. The API proxies will be used by different apps; you'd like to independently manage access to the different resources protected by those proxies.

None of these conditions seem to apply to the situation you described.

If you have several resources on the same backend (in your case, these would be: wmts, copyright, tiles), and the same authorization checks apply to all those resources, and the same person (you) is implementing the rules for all these resources, in my opinion, it would be better to use a single API proxy for that purpose.

Even if you use a single API Proxy, you can get analytics on the different calls that get sent in. For example, you can analyze the breakdown between calls for wmts vs tile vs copyright, by developer app, or by user.

The question of the number of targets to have, is an independent one. Since you have two distinct domains for the different targets, it makes sense to have multiple targets, one for each domain, and a simple RouteRule to direct the request to the appropriate target. For example

  <RouteRule name='backend1'>
    <Condition>proxy.pathsuffix =| '/copyright'</Condition>
    <TargetEndpoint>backend1</TargetEndpoint>
  </RouteRule>
  <RouteRule name='backend2'>
    <TargetEndpoint>backend2</TargetEndpoint>
  </RouteRule>

[#3]

Hi @Dino,

One small remark:" If you have several resources on the same backend (in your case, these would be: wmts, copyright, tiles), and the same authorization checks apply to all those resources, and the same person (you) is implementing the rules for all these resources, in my opinion, it would be better to use a single API proxy for that purpose."

I don't fully understand this. Should I have one API proxy file with one basepath and the rest (/wmts, /copyright, /tile) set as resources through conditional flows? I would be very useful for me if you could paste the xml as an example for this configuration.

Please note that I actually have 2 different backends: Bk1 goes to backendOne.domain.com while Bk2 and Bk3 both point to backendTwo.domain.com. Would you therefore say that I should have 2 basepaths in one API proxy?

[#4]

Hi @Emilia Ipate

Applying DRY principle is a good way to optimize implementation aspect. Based on the information available as part of the question, I will suggest to go with single API proxy.

Cheers,