API design to allow client to pick server

user_6611672 0
Viewed 133

I have the following basic architecture:

enter image description here

For reasons I don't want to get into, I want to allow the client to fetch data from either server if they so choose. If they don't care then the load balancer will decide for them.

Is there a best practice for designing the API request?

I've come up with a few options:

  • Add an optional query string parameter:
example.com?server=1
  • Add an optional request header (not sure if there's an existing header or if I should create a custom one):
example.com -H "Server-ID: 1"
load-balancing request rest http
3 Answers

Just create the public domain name for the servers that you allow client to call it directly and then configure the DNS such that it can route the request to them or to the load balancer depending on the domain name of the HTTP request.

For example, you may have the following domain names for the servers:

  • api.example.com for the load balancer
  • api-server1.example.com for Server1
  • api-server2.example.com for Server2

Then ask the clients to choose which servers to use by configuring the corresponding domain name in the API call.

One of the real-life example is Mixpanel API. You can see that they have two kind of the servers to let the API client to choose which to use through different domain names.

user_3396370

I'm sorry but do you have access to the load balancer's code? Because if you do, you can have the load balancer ask the user.

If it's a Website, maybe the load balancer returns a simple radio form where the user has to select from either Auto, Server 1 or Server 2. Auto will cause the load balancer to decide on its' own.

If it's a app, then the app can automatically ask the user between server 1, 2 and auto. For best UI/UX practices though, Auto should be selected/checked by default.

If you don't have a lot of control maybe direct the the user to the server using lesser system resources which will then send the form?

But it seems that it's something else. I feel with the mention of the term "fetch" your client-side back-end code will communicate with the server?

That really shouldn't matter much in that case since the user doesn't have to remember anything. It could be a subdomain of 1204829.yourdomain.extension and whatever. I won't recommend something like this though:

POST example.com
some headers:some values

`
{
"server":1
//other data
}
`

Why I'm saying so is because the last thing server (or the load balancer) will receive is the body of a POST request.

So yeah, subdomain is better because that's the first thing a server will receive. Then, the URL parameters and then the headers followed by the body (absent in the most common GET request). I've told you as much as I knew, hope you're able to come to a conclusion!

The thing is, you're worrying too much on a very small thing. It doesn't matter how. Just focus on making that app!

user_143604460

I ended up implementing this through an HTTP header:

GET example.com                    # server 1 or 2 (load balancer decides)
GET example.com -H "Server-ID: 1"  # routes to server 1
GET example.com -H "Server-ID: 2"  # routes to server 2
user_66116720
Related