请，任何人都可以分化之间的系统API和进程API？请以通用术语提供答案，因为我无法在互联网上找到。
小智 7
系统 API 从现有系统中抽象出来。它用系统的语言与系统对话（例如，SOAP、直接Java 调用、SAP 调用等）。它向外界提供了一个干净的 API（通常是带有 http 和 json 的 REST）。当您很好地实现系统 api 时，您可以将现有系统与不同/新的系统进行交换，而无需向外界更改系统 api 的 api：只需使用不同的适配器逻辑实现一个新的系统 api 即可。
流程 api 应该在“两端”都进行 REST 通信。它调用一个或多个系统 API 来完成其工作。process api 编排不同的作业。
当您需要更多信息时，请使用“api led communications”进行搜索
系统 API 是在系统之上构建的层，它处理所有系统特定的连接怪癖和设置。然后，它以标准格式（通常是 REST，但您可以自由选择其他格式，例如 SOAP）向 API 的其余部分公开这些资源及其逻辑。正如罗杰·布特努斯所说：
“当你很好地实现了系统 api 时，你可以将现有系统与不同的/新的系统进行交换，而无需向外界更改系统 api 的 api：只需使用不同的适配器逻辑实现一个新的系统 api 即可。”
流程 API 是您保存逻辑和编排的地方，它不直接与终端系统“对话”，而是连接到系统 API 来获取数据。理想情况下，流程 API 应该只在双方上进行 REST 通信，并且可以聚合来自多个系统的数据。
复杂流程 API 的一个示例是“您订购的商品”API，它接受用户 ID 作为输入，然后与 CRM 系统的系统 API 进行对话以获取“订单历史记录系统 API”使用的 ID ”。但是，此 API 可能仅返回订单列表，除了文章 ID 之外，没有任何文章信息。因此，我们的 Process API 然后使用从“文章信息系统 API”获取的文章信息以及列表中的 id 来丰富此列表。
我知道这超出了问题的范围，但为了完整起见，我也会简短地解释第三种变体：
体验 API 可以被视为进入 API 网络的门户，每个（类型）客户端都有不同的信息需求，并且可以使用不同的协议进行通信。Experience API 负责以客户支持的格式提供客户所需的所有信息。这使得客户不再需要知道需要从哪里获取信息。（来自 CRM 的客户信息、来自专有系统的订单信息、来自文章 DB 的文章信息）这种设计概念的一个好处是，例如，如果您公司正在制作的移动应用程序获得了一些需要额外数据的新功能。您可以更新“移动应用程序体验 api”，这将使您的“超级昂贵的 IBM Experience api”保持不变。降低开发成本，因为您不需要对其他 api 使用者进行任何更改，如果您只有一个 api，就会出现这种情况。
| 归档时间： |
|
| 查看次数： |
24510 次 |
| 最近记录： |