经验API :制定经验API的方法

Question

我们的平台架构是围绕由Mulesoft(文档)设计的API主导的连接构建的。

因此，这个体系结构帮助我们识别和分类我们的微服务。这里棘手的部分，或者可能是我困惑的部分是经验API。因此，我想在一个应用程序-> one平台(可重用)的上下文中探讨几个问题。我们能有多个经验API吗？如果是，那么我们如何确定一个候选人的经验API？

Mulesoft将体验层定义为

体验层:数据现在通过一组广泛的通道使用，每个通道都希望访问相同的数据，但形式不同。例如，零售分支POS系统、电子商务站点和移动购物应用程序都可能希望访问相同的客户信息字段，但每个字段都需要以非常不同的格式提供这些信息。经验API是一种可以重新配置数据的方法，使其最容易被预期的对象所使用，所有这些都来自一个公共数据源，而不是为每个通道设置单独的点对点集成。

因此，如果经验API不分开，它们很快就会被很多东西(以转换的名义&添加特定于应用程序的逻辑)而膨胀。那么，一个经验API在这方面应该做多少？一个处理它们的一般方法将有助于一些实际的例子。

Answer 1

经验API旨在简化特定客户端类型访问数据的方式。

例如，您需要将订单信息从SAP公开到桌面和移动应用程序。

系统层

• (此API从SAP获取原始数据)

工艺层

• (此API提供订单数据的规范视图)。直接由桌面客户端访问)

体验层

• 移动订单API (由于移动客户端有数据限制，此API从订单信息API提供了一组减少的数据和分页)

基顿