【问题标题】:Large Scale Enterprise API Design大规模企业 API 设计
【发布时间】:2016-09-02 17:08:46
【问题描述】:

我需要关于如何最好地为大型企业应用程序实现 API 的建议,这些应用程序有几个子 Web 应用程序在根应用程序中运行。例如 Root、Child1 和 Child2

在 IIS 中托管的每个应用程序都有单独的 MVP 项目。 MVC 应用程序只有前端逻辑,业务和数据访问层托管在另一个 WCF 项目中(每个孩子都有一个单独的 WCF 项目)。前端 MVC 应用程序仅将请求路由到目标 WCF 应用程序。

现在我计划为每个应用程序设计 API。我无法决定是否应该创建一个单独的应用程序来保存所有子应用程序和根应用程序的 API,还是应该在每个应用程序中添加 API。与前端 MVC 项目一样,API 也会重定向到集中式 WCF 应用程序。

有一个适用于所有 API 的通用逻辑(速率限制、身份验证等),如果 API 在每个应用程序中,那么我将不得不在所有三个应用程序中复制逻辑。

【问题讨论】:

  • API 的速率限制是针对所有的,还是单独的?您是否需要单独部署 API?任何缩放差异?
  • @tomliversidge 是的,API 的速率限制和其他属性适用于所有 API。不需要单独部署 API,我可以将它们全部组合到一个应用程序中。
  • 如果 API 是独立的,您如何计划跨 API 的速率限制?
  • 如果您将它们全部组合到一个应用程序中,您还没有回答自己的问题吗?
  • @tomliversidge 谢谢,我现在想保持所有 API 的速率限制相同。将来,不同的 API 可能会有所不同。我想知道最佳实践是什么,将所有 API 保存在一个应用程序中或在相关应用程序中添加 API。

标签: asp.net-mvc api architecture


【解决方案1】:

无论哪种方式都需要权衡取舍。

开发独立 API 的优势包括:

  1. 隔离
  2. 更容易更改
  3. 可独立部署,即可以独立扩展
  4. 如果不同的开发团队参与不同的 API,可能会更容易

缺点包括:

  1. 需要决定是要在每个 API 中重复公共代码还是提取公共共享模块(这会降低隔离优势)
  2. 需要处理更多基础架构/操作
  3. 如果您想要协调所有 API 的速率限制,这比使用单个 API 更难

我的默认立场是开发单独的 API,但您的特定用例(将请求路由到其他事物)可能会通过一些现有工具(例如 nginx)来解决 - 我对这些不了解,因此无法提供建议

【讨论】:

  • 谢谢,我计划使用单独的应用程序来保存所有 API。
猜你喜欢
  • 2011-05-17
  • 1970-01-01
  • 2011-04-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-08-29
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多