API设计 - 分裂成不同的子域（微服务）

Question

我们的应用程序基于API第一体系结构，目前基于单个域/服务：

api.todos.com

API的消费者分别是：

• 我们网络的前端
• 我们的移动应用
• 其他业务/公共

我们将建立新的微服务为不同的语言编写的相同的应用程序。例如，我们可以开发API服务：

• 统计
• 博客/内容
• RSS订阅
• 搜索

我的问题是围绕处理领域。最好是将每个服务分成不同的子域，例如

• api.todos.com
• stats.todos.com
• content.todos.com
• rss.todos.com
• search.todos.com

或者是它最好有我们做一个统一的API域HTTP（第7层）路由到达到我们的终点。例如

• api.todos.com/todos
• api.todos.com/stats
• api.todos.com/content
• api.todos.com/rss
• api.todos.com/search

不知道这是最好的公共API？拥有多个子域会更容易，不必处理中间路由层/代理。

Answer 1

作为系统架构师，我认为it is better to have a single unified API domain where we do HTTP (layer 7) routing to reach our endpoints。您可以让您的系统更灵活，而无需为您的客户进行任何更改。例如你有一个航线的microService：

• api.todos.com/route1
• api.todos.com/route2

在未来，你可以通过这个途径分裂微服务。

但大多数情况下，它取决于您使用的API网关。 API网关是您系统中的单一入口点，以及更正微服务的代理请求。它也使auth和缓存。更多关于这个微服务的模式，你可以阅读here。