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

Question

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

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

1. 基于渠道/消费者 专为 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 对象重复的机会增加

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

uri 示例：

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

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

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

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

uri 示例：

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

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

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

谢谢。

Answer 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 中表示这个是个好主意。