体验 API：制定体验 API 的方法答案

【问题标题】：Experience API : Approaches to formulating an Experience API体验 API：制定体验 API 的方法
【发布时间】：2019-12-08 21:13:39
【问题描述】：

我们的平台架构是围绕由 Mulesoft(Doc) 设计的 API Led Connectivity 构建的。

所以这种架构可以帮助我们识别和分类我们的微服务。这里棘手的部分或者我感到困惑的部分是体验 API。所以我想在一个应用程序 -> 一个平台（可重用）的背景下探讨几个问题。我们可以有多个体验 API 吗？如果是，那么我们如何确定 Experience API 的候选人？

Mulesoft 将体验层定义为

体验层：数据现在被广泛使用通道，每个通道都希望访问相同的数据，但方式多种多样的不同形式。例如，零售分支机构 POS 系统、电子商务网站和移动购物应用程序可能都希望访问相同的客户信息字段，但每个字段都需要不同格式的信息。体验 API 是手段通过它可以重新配置数据，使其最容易被使用由其目标受众，全部来自一个共同的数据源，而不是为每个通道设置单独的点对点集成。

因此，如果体验 API 没有分开，它们很快就会变得臃肿，包含很多东西（以转换和添加特定于应用程序的逻辑的名义）。那么体验 API 在这方面应该做多少呢？用一些实际的例子来接近它们的一般方法会有所帮助。

【问题讨论】：

那我们可以在体验层做转换吗？
我会这样认为，基于这种理念

标签： architecture microservices api-design mulesoft

【解决方案1】：

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

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

系统层

SAP Order API（此 API 从 SAP 中获取原始数据）

流程层

订单信息 API（此 API 提供订单数据的规范视图。桌面客户端可直接访问）

体验层

移动订单 API（此 API 提供了来自订单信息 API 的一组精简数据和分页，因为移动客户端有数据限制）

基顿

【讨论】：

“我们可以为单个客户端提供多个体验 API 吗？如果是，那么我们如何确定体验 API 的候选者？” - 对此有何想法？
是的。就像您将按域上下文分解您的“流程层”API 一样……例如发票、客户、联系人、订单等……您将对“体验层”做同样的事情，例如 Invoice Mobile、Invoice IOT 、发票打印机、客户手机等。将所有这些都放在一个 API 中是个坏主意。
@KeatonVictor，我有一个类似的问题，偶然发现了这篇文章。感谢您的回答。澄清一下，假设我有 2 个客户 - Web 和 Mobile，都需要客户地址，但有两种完全不同的地址格式。所以您的建议是拥有 2 个体验 API -- -1) GET: /customer-web/address 2) GET: /customer-mobile/address。我的理解正确吗？我们实际上是在 URL 中识别“调用者”。 REST 标准是否可以接受？
嗨 @Joe 是的，我会推荐 2 个体验 API。体验 API 的作用是提供为客户端（例如 Web、移动、物联网设备）量身定制的数据的特定视图......使用 URL 表示不同的客户端是一种选择，但不是最佳实践。更清洁的选择是使用以下之一。 (1) 客户标头，例如 X-Consumer (2) 使用子域，例如 client-1.myapi.com/address (3) 让 API 消费者知道，这样它将根据经过身份验证的用户定制响应......每个都带有 pro /缺点。如果您想讨论更多选项，请联系我 keaton@pattnr.com