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

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

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

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

uri示例：

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

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

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

Pro:-应用特定于渠道的策略更容易，管理更容易，停机窗口更小

缺点：-可重用性减少了跨api复制对象的机会

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

uri示例：

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

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

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

支持：-促进可重用性，渠道不可知，相同的api可以在不同的消费者之间使用

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

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

uri示例：

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

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

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

Pro的：渠道不可知，相同的api可以在不同的消费者之间使用

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

---

谢谢。

据我所知，你的问题；您想知道体验API的端点将使用什么URI，对吗

基于（2017年7月12日）

经验API包括：

体验API是数据可被访问的手段 重新配置，使其最容易被其预期用途使用 受众，都来自一个公共数据源，而不是设置 每个通道单独的点对点集成。经历 API通常是按照API优先设计原则创建的 是为特定的用户体验而设计的

根据MuleSoft的示例和我的理解，experience API是为一个给定的“体验”创建的；网络、虚拟现实、移动等

您正试图为给定的特殊体验创建一个API，以使该特定客户机易于使用该API

根据我的理解，这个级别的主要目标不是可重用性。您关注的是系统API和流程API级别的可重用性，但体验API应该通过提供他们所需的接口和数据，使不同客户的开发人员的生活更轻松，这样他们就不必直接与系统和流程API通信，但他们得到了定制的API，完全适合他们的特殊需要

---

因为体验API是为特殊体验/渠道/客户端应用程序量身定制的；我认为在URI中反映这一点是一个好主意。

感谢您的见解@Attila。这消除了我们的许多疑虑。如果超过70%的消费者期望相同的体验，那么我只是想知道如何设计体验api？您如何减轻该场景中的回归测试？API的常用部分（共享体验/功能）可以由不同顶级体验API之间共享的API实现。实际上，没有什么可以阻止您在Experience API层中定义多个级别的API。（与图片上的过程API类似）。你也考虑过四处打听吗？那里的一些人对API设计和Mule ESB有着深刻的理解。