体验 API 的 Mule API 主导的连接设计方法

Posted 2023-03-24

【中文标题】体验 API 的 Mule API 主导的连接设计方法

【英文标题】：Mule API Led Connectivity Design Approaches for Experience API

【发布时间】：2018-08-28 16:52:13

【问题描述】：

作为我们实现以 API 为主导的连接性之旅的一部分，我们必须将我们的资源（即 API 端点）分组到多个 Mule 应用程序中以获取体验 API。 为了使 Mule 应用程序具有有意义的名称，同时保持最大的可重用性，而不是将消费者名称与应用程序名称相关联（这使得体验 API 与当前应用程序环境紧密耦合），我们建议使用 Mule 应用程序名称反映业务的本质。

选项列表如下。你觉得哪一个更理想？您在组织中使用了什么方法？

基于渠道/消费者 专为 WEB、CRM、移动等消费者提供的体验 API。

uri 示例：

www.example.com/example-**web**-application/v1/  
www.example.com/example-**crm**-application/v1/
www.example.com/example-**mobile**-application/v1/

专业人士：- 应用渠道特定政策更容易，管理变得更容易，停电窗口更小

缺点：- 可重用性降低，跨 api 对象重复的机会增加

基于业务领域 使用公司数据模型。例如 - 客户、产品、付款等。

uri 示例：

www.example.com/example-**customers**-application/v1/
www.example.com/example-**products**-application/v1/ 
www.example.com/example-**payments**-application/v1/

专业人士：- 促进可重用性，与渠道无关，相同的 api 可用于不同的消费者。

缺点：管理可能会变得复杂，停机窗口更大，多个消费者可能会受到影响

基于客户旅程 这种方法与客户在组织中的生命周期相关联。例如 - 潜在客户 --> 潜在客户 --> 参与 --> 付款 --> 客户保留

uri 示例：

www.example.com/example-**prospect**-application/v1/  
www.example.com/example-**lead**-application/v1/
www.example.com/example-**engage**-application/v1/

专业人士：与渠道无关，相同的 api 可用于不同的消费者。

缺点：可能会变得越来越大，可能仍需要进一步细分

谢谢。

【参考方案1】：

据我了解您的问题； 您想知道将哪些 URI 用于体验 API 的端点，对吗？

基于a recent blog entry from mulesoft（2017 年 7 月 12 日）。

体验 API 是：

体验 API 是数据可用于 重新配置，使其最容易被预期使用 观众，全部来自公共数据源，而不是设置 每个通道的单独点对点集成。体验 API 通常是使用 API 优先的设计原则创建的，其中 API 专为特定的用户体验而设计。

基于 MuleSoft 的示例和我的理解，体验 API 是为给定的“体验”创建的；网络、虚拟现实、移动设备等...

您正在尝试为给定的特殊体验创建 API，以使该特定客户端可以轻松使用 API。

据我了解，此级别的主要目标不是可重用性。您专注于系统 API 和流程 API 级别的可重用性，但体验 API 应该通过提供他们需要的接口和数据来使不同客户端的开发人员的生活更轻松，这样他们就不必进行通信直接使用系统和流程 API，但他们会获得量身定制的 API，完全适合他们的特殊需求。

由于体验API是为特殊体验/渠道/客户端应用量身定制的；我认为在 URI 中表示这个是个好主意。

【讨论】：

感谢您的见解@Attila。解开了我们的很多疑惑。如果超过 70% 的消费者期望相同的体验，只是想知道如何设计体验 API？在这种情况下，您如何减轻回归测试的影响？

API 的常用部分（共享体验/功能）可以由不同***体验 API 之间共享的 API 来实现。实际上，没有什么能阻止您在 Experience API 层中定义多个级别的 API。 （就像图片上的流程 API 一样）。您是否也考虑过在forums.mulesoft.com 上询问？那里有些人对 API 设计和 Mule ESB 有非常深刻的理解。