系统 API 和进程 API 有什么区别?

9
请问有人能简单区分“系统API”和“进程API”吗?请用通俗易懂的语言回答,因为我在网上找不到相关信息。

请参阅 https://blogs.mulesoft.com/dev/api-dev/what-is-api-led-connectivity/,了解有关API导向连接的信息。 - Michael Freidgeim
6个回答

7
一个系统API抽象出现有的系统。它使用系统语言(如SOAP,直接Java调用,SAP调用等)与系统交互。对外提供一个干净的API(通常是REST with http和json)。当您实现系统API时,如果做得好,可以在不改变系统API对外部世界的情况下将现有系统更换为不同/新系统:只需使用不同的适配器逻辑实现新的系统API。
一个过程API应该在“两端”上都使用REST。它调用一个或多个系统API来完成其工作。过程API协调不同的工作。
需要更多信息时,请搜索“api led connectivity”。

4
系统 API 是建立在系统之上的一层,处理所有特定于系统的连接问题和设置。然后以标准格式(通常是 REST,但您可以选择其他类似 SOAP 的格式)公开这些资源和逻辑给其它 API。正如 Roger Butenuth 所说:
“当您成功实现系统 API 时,您可以替换现有的系统而不改变系统 API 对外部的 API。只需使用不同的适配器逻辑实现新的系统 API。”
流程 API 是您保留逻辑和编排的地方,它不直接与终端系统通信,而是连接到系统 API 来获取数据。流程 API 应该理想情况下在两侧都仅使用 REST,并且可以从多个系统聚合数据。
一个复杂过程 API 的例子是 "您已订购的物品" API,其中输入用户 ID,然后连接到 CRM 系统的系统 API 获取 "订单历史系统 API" 使用的 ID。但是该 API 可能仅返回一个订单列表,除了文章 ID 之外没有任何文章信息。因此,我们的流程 API 就会使用列表中的 ID 从 "文章信息系统 API" 提取的文章信息来丰富此列表。
我知道这超出了问题的范围,但为了完整起见,我也将简要解释第三种变体:
经验 API 可视为进入您的 API 网络的门户,每个(类型的)客户端都有不同的信息需求并且可以使用不同的协议进行通讯。经验 API 的责任是以客户端支持的格式提供客户端所需的所有信息。这使得客户端无需知道需要从哪里获取信息。
(来自 CRM 的客户信息,来自专有系统的订单信息,来自文章数据库的文章信息)。此设计概念的奖励是,如果例如您的公司正在制作的移动应用程序获得了某些新功能需要额外的数据,您可以更新 "移动应用程序体验 API",而不会更改“超级昂贵 IBM 体验 API”。这样可以减少开发成本,因为您无需在其它 API 消费者中实施任何更改,如果只有一个 API,这将是情况。

2
系统API是所有IT设计的基础,是记录中心框架,由于其复杂性和网络问题通常不容易访问。API提供一种隐藏该复杂性的方法,同时揭示数据并提供对任何接口更改或这些系统合理化的下游保护。
过程API体现了与源和目标系统或通道通过一系列系统API相互作用的基本业务流程。例如,在购买订单过程中,有一些逻辑在产品、地理位置和零售渠道之间是共同的,它们应该被精炼成一个单一的服务,然后可以调用。
您可以从这篇文章中获得更多的清晰度:https://dzone.com/articles/api-the-backbone-of-the-software-industry-know-how

2

我认为主要的区别在于你实施业务流程和规则/逻辑的地方。

系统API是原子API,可以用于构建更高级别的API(体验API),在您的设计范围内。过程API是编排层,在这里您可以使用Mulesoft流来实现业务流程或逻辑。


2

系统API执行CRUD操作的繁重工作。 进程API专注于业务逻辑。


1

系统 API 和进程 API 将成为 API led 连接的一部分。

系统 API 类似于主数据库或 SaaS 平台的包装服务。

进程 API 涉及应用程序逻辑,以验证搜索或查询参数。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接