API 允许客户端选择服务器的设计
API design to allow client to pick server
我有以下基本架构：
由于我不想深入的原因，我想允许客户端从任一服务器获取数据（如果他们愿意的话）。如果他们不在乎，那么负载均衡器将为他们做出决定。
是否有设计 API 请求的最佳实践？
我想出了几个选项：
- 添加一个可选的查询字符串参数：
example.com?server=1
- 添加一个可选请求header（不确定是否存在现有的header或者我是否应该创建一个自定义请求）：
example.com -H "Server-ID: 1"
只需为允许客户端直接调用的服务器创建 public 域名，然后配置 DNS，以便它可以根据域名将请求路由到它们或负载均衡器HTTP 请求。
例如，您可能有以下服务器域名：
api.example.com 用于负载平衡器api-server1.example.com 服务器 1api-server2.example.com 服务器 2
然后让客户端通过在API调用中配置相应的域名来选择使用哪些服务器。
现实生活中的一个例子是Mixpanel API。你可以看到他们有两种服务器让API客户端通过不同的域名来选择使用哪一种。
抱歉，您可以访问负载均衡器的代码吗？
因为如果这样做，您可以让负载均衡器询问用户。
如果它是一个网站，可能负载平衡器 returns 是一个简单的无线电表单，用户必须从自动、服务器 1 或服务器 2 select。
自动将使负载平衡器自行决定。
如果是app，那么app可以自动询问服务器1、2和auto之间的用户。
不过，为了获得最佳 UI/UX 实践，默认情况下自动应为 selected/checked。
如果您没有太多控制权，可以使用较少的系统资源将用户定向到服务器，然后由服务器发送表单？
不过好像是另外一回事。我觉得提到术语“获取”，您的 client-side back-end 代码将与服务器通信？
在那种情况下，这真的无关紧要，因为用户不必记住任何东西。它可能是 1204829.yourdomain.extension 的子域
等等。
不过我不会推荐这样的东西：
POST example.com
some headers:some values
`
{
"server":1
//other data
}
`
为什么我这么说是因为服务器（或负载均衡器）将收到的最后一件事是 POST 请求的 body。
是的，子域更好，因为这是服务器收到的第一件事。然后是 URL 参数，然后是 headers，然后是 body（在最常见的 GET 请求中不存在）。
我知道的都告诉你了，希望你能得出结论！
问题是，你在一件非常小的事情上担心太多了。
怎么样都无所谓。专注于制作该应用！
我最终通过 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
我有以下基本架构：
由于我不想深入的原因，我想允许客户端从任一服务器获取数据（如果他们愿意的话）。如果他们不在乎，那么负载均衡器将为他们做出决定。
是否有设计 API 请求的最佳实践？
我想出了几个选项：
- 添加一个可选的查询字符串参数：
example.com?server=1
- 添加一个可选请求header（不确定是否存在现有的header或者我是否应该创建一个自定义请求）：
example.com -H "Server-ID: 1"
只需为允许客户端直接调用的服务器创建 public 域名，然后配置 DNS，以便它可以根据域名将请求路由到它们或负载均衡器HTTP 请求。
例如，您可能有以下服务器域名：
api.example.com用于负载平衡器api-server1.example.com服务器 1api-server2.example.com服务器 2
然后让客户端通过在API调用中配置相应的域名来选择使用哪些服务器。
现实生活中的一个例子是Mixpanel API。你可以看到他们有两种服务器让API客户端通过不同的域名来选择使用哪一种。
抱歉，您可以访问负载均衡器的代码吗？ 因为如果这样做，您可以让负载均衡器询问用户。
如果它是一个网站，可能负载平衡器 returns 是一个简单的无线电表单，用户必须从自动、服务器 1 或服务器 2 select。 自动将使负载平衡器自行决定。
如果是app，那么app可以自动询问服务器1、2和auto之间的用户。 不过，为了获得最佳 UI/UX 实践，默认情况下自动应为 selected/checked。
如果您没有太多控制权，可以使用较少的系统资源将用户定向到服务器，然后由服务器发送表单？
不过好像是另外一回事。我觉得提到术语“获取”，您的 client-side back-end 代码将与服务器通信？
在那种情况下，这真的无关紧要，因为用户不必记住任何东西。它可能是 1204829.yourdomain.extension 的子域 等等。 不过我不会推荐这样的东西：
POST example.com
some headers:some values
`
{
"server":1
//other data
}
`
为什么我这么说是因为服务器（或负载均衡器）将收到的最后一件事是 POST 请求的 body。
是的，子域更好，因为这是服务器收到的第一件事。然后是 URL 参数，然后是 headers，然后是 body（在最常见的 GET 请求中不存在）。 我知道的都告诉你了，希望你能得出结论！
问题是，你在一件非常小的事情上担心太多了。 怎么样都无所谓。专注于制作该应用！
我最终通过 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