提出这个问题的主要原因是了解使用系统 API 的最佳实践背后的原因/原因。如果 System API 本身足以满足我的客户端应用程序的目的，我们是否还需要编写一个体验 API 来间接调用系统 API，或者打破规则，直接从客户端应用程序调用系统 API。有时，它是网络上的开销/大量 API 调用。
问问题
434 次
1 回答
0
System API 用于解锁或暴露系统资产（后端数据）。现在，人们可以编写系统 API，使其从系统数据库中获取数据，进行所需的处理，例如将表行转换为 JSON 格式，然后对字段进行一些丰富和修剪并将其公开给客户A. 这是一个课程粒度的方法。现在，另一个客户 B 需要类似的数据，但需要您已经修剪的一些字段来为客户 A 提供服务，客户 A 只需要您从系统（数据库）中选择的许多字段中的几个字段。您必须为客户 B 编写单独的课程粒度 API。此外，如果将来后端 SYSTEM 被新的 SYSTEM 替换，则必须为每个客户 A 和客户 B 重新编写/更新 API .
这种课程粒度的方法每次都可以解决您的问题，但是在架构上，将大型服务分解为多层经验、流程和系统 API 的细粒度方法将能够实现重用、减少工作量、增加上市时间、降低总拥有成本，并允许通过体验 API 层为每个客户端应用所需的单独策略（安全性、SLA 等）。您现在可以更好地扩展您的集成环境。
细粒度的方法会增加资源的使用，例如网络、磁盘空间（更多日志记录）等，但它是对您获得的所有优势的权衡。同样，采用任何一种方法的决定都应该与您的生态系统的当前情况保持一致，所以这一切都取决于。
于 2019-09-20T15:46:49.433 回答