问web服务的域名与URL路径

EN

更新:这是一个旧的答案，暗示HTTP/1.1。对于HTTP/2，逻辑大致相同，但多路复用除外，如果两端都支持，则允许每个主机拥有一个TCP连接。

这是一个有趣而重要的问题，我很惊讶它没有得到太多的关注。

除了@thexacre的响应之外，您还需要考虑客户端的行为以及它如何选择重用连接。从客户端的角度来看，主机是一个单独的实体，可以向一个HTTP连接( Keep-alive特性)内的不同路径提供请求。例如，保持活动超时可以是一分钟，但可以在客户端进行配置，并与服务器进行协商。第二个因素是客户端的最大同时连接数，也是可配置的，但通常限制在节省资源上。

尽管如此，您需要查看客户端调用每个端点的频率，以及客户机是否将受益于HTTP连接重用。从客户端的角度来看，单主机+多路径策略似乎更方便，因为它可能选择同时发送多个请求，或者根据是否要节省本地资源(内存和CPU)或尽可能快地检索数据而序列化它们。

另一方面，如果客户端必须处理多个主机名，这意味着它将与每个主机创建单独的HTTP连接；连接重用将是不可能的。

然后是服务器端。如果您正在运行一个微服务体系结构，这意味着您需要一个请求路由器，这是一个潜在的瓶颈。从服务器的角度来看，为逻辑上隔离的端点组设置单独的主机名更为方便:您可以灵活地选择体系结构(microservice与单块)、稍后更改体系结构、迁移(如另一个答案中提到的那样)、可能不需要路由器等等。

总之，我要说的是，如果客户机可以在有限的时间内提出大量请求，而且如果在客户端有效地处理它们是很重要的，那么客户机将受益于较少的主机名，最好只是一个。但是，如果客户机一次只发出几个请求，那么请考虑什么是对您的服务最好的，这更可能是多个主机名。

是否有理由选择dev.taxService.api.company.com或dev.company.com/api/taxService？

似乎基本上你的问题归结为是使用子域还是子目录来分离服务比较好。

例如，篱笆两边似乎都有很多人：

Google似乎更喜欢子目录，以下是两个不同服务的例子：

• Gmail服务：https://www.googleapis.com/upload/gmail/v1/users/userId/drafts
• 分析服务：https://www.googleapis.com/analytics/v3/data/mcf

例如，亚马逊似乎更喜欢子域名：

• SQS：http://sqs.eu-west-1.amazonaws.com/
• S3：http://s3-sa-east-1.amazonaws.com/

就我个人而言，我更喜欢子域，因为：

• 它们不需要负载均衡器/反向代理将子目录映射到服务。
• 子目录在HTTP上下文中是有意义的，但是如果您的服务涉及其他协议，那么它可能不会。
• 通常，使用子域在基础设施提供者之间拆分服务比较容易，这在迁移过程中很有用。即。通过将子域指向提供者B，您可以轻松地将服务1移动到提供者B，而服务2仍然位于提供者A上。使用子目录这样做可能需要您将代理反向到一个完全独立的数据中心。