以 API 为主导的连接的 Mulesoft 最佳实践，是不是可以直接从客户端应用程序调用系统 API（无论是网络/移动）

Posted 2023-03-24

【中文标题】以 API 为主导的连接的 Mulesoft 最佳实践，是不是可以直接从客户端应用程序调用系统 API（无论是网络/移动）

【英文标题】：Mulesoft best practices for API-led connectivity , is it okay to invoke System API directly from the client application(be it web/mobile)以 API 为主导的连接的 Mulesoft 最佳实践，是否可以直接从客户端应用程序调用系统 API（无论是网络/移动）

【发布时间】：2019-11-28 20:58:30

【问题描述】：

提出这个问题的主要原因是了解使用系统 API 的最佳做法背后的原因/原因。如果 System API 本身足以满足我的客户端应用程序的目的，我们是否还需要编写一个体验 API 来间接调用系统 API，或者打破规则，直接从客户端应用程序调用系统 API。有时，这是通过网络进行的开销/大量 API 调用。

【参考方案1】：

系统 API 用于解锁或公开系统资产（后端数据）。现在，可以编写系统 API，使其从系统数据库中获取数据，进行所需的处理，例如将表行转换为 JSON 格式，然后对字段进行一些丰富和修剪并将其公开给客户A. 这是一个课程粒度的方法。现在，另一个客户 B 需要类似的数据，但需要您已经修剪的一些字段来为客户 A 提供服务，客户 A 只需要您从系统（数据库）中选择的许多字段中的几个字段。您必须为客户 B 编写单独的课程粒度 API。 此外，将来如果后端 SYSTEM 被新的 SYSTEM 替换，则必须为每个客户 A 和客户 B 重新编写/更新 API。

这种课程粒度的方法每次都能解决您的问题，但在架构上采用细粒度的方法将大型服务分解为多个经验层、流程和系统 API 可以实现重用、减少工作量、增加时间市场，降低总拥有成本，并允许通过体验 API 层为每个客户端应用所需的单独策略（安全性、SLA 等）。您现在可以更好地扩展您的集成环境。

细粒度的方法会增加资源的使用，例如网络、磁盘空间（更多日志记录）等，但它会权衡您获得的所有优势。同样，采用任何一种方法的决定都应与您的生态系统的当前情况保持一致，因此这一切都取决于。

【讨论】：

感谢 Rohan 的回复，对延迟回复表示抱歉。