同步 API 和异步 API 之间的区别

应用程序编程接口 (API) 是现代网络的支柱，连接各种系统并解锁协作流程。在 API 通信的背景下，出现了两种通用范例：同步服务和异步服务。

同步和异步设计是 API 设计的基本原则，了解它们的区别、优点和缺点对于新手和资深开发人员都至关重要。下面，我们将比较这两种范式之间的差异，并回顾每种范式使用的确切格式、协议和框架。

同步 API

同步 API 的操作流程非常简单。当客户端向服务器发出请求时，它会等待该服务器的响应，然后再继续。同步 API 类似于电话上的双向对话，双方发言并等待对方回复或发言后再继续。同步 API 通常是需要实时连接的交互的首选方法，在现代 Web上的微服务环境中非常常见。

同步工作流

同步工作流程大致可分为三个阶段：

请求：客户端向服务器发出请求以执行特定操作。此操作可以包括检索资源、编辑实体，甚至将此请求转发到其他地方。
处理：服务器处理请求并根据请求的类型和模式准备适当的响应。在此处理过程中，客户端基本上处于空闲状态，等待响应。
响应：服务器将响应发送回请求实体。此响应可以是请求的数据，也可以是功能已执行的确认（例如资源已被删除或消息已被转发）。完成此步骤后，客户端可以自由地发出新请求。

同步用例

当需要即时性时，最好使用同步 API。处理数据库表示或外部资源时，可能需要即时性。1:1 的转换需求可能还需要同步通信来跨资源镜像状态，例如协作编辑文档时。

最终，无论何时资源被更改或修改，最好使用同步 API，并且在发生此类更改或修改时必须将该更改或修改传达给客户端。

优点和缺点

优点

同步 API 的实现相对简单，这意味着它们的开发和维护成本通常较低。同步 API 还提供即时反馈，许多开发人员可能会发现它更容易用于辅助应用程序。同步还可以为许多应用程序带来更持久的准确性和特异性，因为在处理请求时，客户端会立即更新其请求的效果。

缺点

实际上，在某些应用中，同步系统效率较低。由于同步系统必须等待客户端的响应，并且在许多情况下等待服务器端的提示，因此当不需要立即同步时，可能会出现大规模扩展和资源效率问题。在某些应用中，您根本不需要同步数据交换。在这些情况下，由于轮询过多，同步交换可能会带来比实际需要更多的成本。

异步 API

异步 API 的运作方式不同。它们允许客户端发出请求，然后继续执行，而无需等待响应。服务器在自己的时间内处理请求，并在准备就绪时返回响应，客户端可以在方便的时候处理、转换和处理数据。打个现实世界的比喻，这类似于邮件——你通过邮件发送一封信，然后在等待回复通过邮箱返回的同时继续你的生活。

异步工作流

请求：客户端向服务器发出请求以执行特定操作。此操作可以包括检索资源、编辑实体，甚至将此请求转发到其他地方。
确认：服务器确认已发出请求，并提供一种机制，客户端可以通过该机制回调以获取状态更新。
处理：服务器像处理任何其他请求一样在后台处理该请求。
通知：服务器通过回调、webhook、消息队列或其他协议通知客户端请求已完成。此时，将提供所请求的信息。或者，也可以提供某事已发生的确认。

异步用例

异步 API在处理请求预计需要时间或不需要立即关注的情况下特别有用。视频或音频处理、批处理文档或定期检查 IoT 设备状态的轮询解决方案都是不需要立即处理的功能的很好案例，这些功能将受益于异步设计。

优点和缺点

优点

异步流程通常非常高效，因为它们不需要任何等待。这可以使服务更好地利用有限的计算和网络能力。这可以带来可扩展性优势，从而可以确定这种处理是否以及何时真正可行。

缺点

异步流程的代码可能更复杂，尤其是考虑到处理后使用通知处理响应所需的设置。虽然异步流程在某些用例中可能更高效，但实现这些流程所需的代码通常会带来成本，而这些成本在更复杂的生态系统中无法很好地扩展。异步系统也不提供实时响应，这意味着它们对于需要即时交互的系统来说处于劣势。

设计考虑

在设计 API 时，开发人员必须尽早决定同步还是异步是合适的动态。以下因素对于此考虑至关重要：

资源可用性和需求：异步环境会因为资源可用性低而扩展响应，从而尽可能延迟响应。因此，异步方法可能更适合不需要即时性的资源密集型应用程序。
开发人员体验：由于响应的即时性，同步 API 通常比异步 API 感觉“更快捷”。如果优先考虑这一点，同步是有意义的。当请求在后台更频繁地发出时，异步可能会胜出。
连续性：同步 API 允许立即更新客户端，从而实现更高的一致性。当客户端发出请求时，该请求会立即得到满足或通过适当的渠道处理。对于异步环境，用户可能需要等待一段时间，这会对请求的当前状态、所触及的资源以及整个系统造成阻碍。
即时性和延迟：当可以容忍或偏好高延迟和低即时性时，异步 API 是最佳选择。当即时反馈和低延迟至关重要时，则需要同步 API。
幂等性：幂等性的概念很简单——当一个操作运行多次时，它应该产生与运行一次相同的输出。这在网络环境较差和客户端类型变化较大的情况下尤其重要。

只要函数本身设计为幂等性，异步和同步系统都可以实现幂等性。尽管如此，异步环境尤其应该携带状态代码和其他数据，以确保最终客户端所接触的服务保持不变，即使围绕该数据的上下文可能会发生变化（例如，即使数据本身正在快速变化，也可以提供 200 代码来确认成功调用数据）。

最佳实践

无论解决方案如何，许多 API 最佳实践仍然适用于这两种模式。以下并非完整列表，但确实为您提供了一些起点！

确保良好的开发人员体验：无论设计选择如何，都要通过高效、全面的开发人员门户进行全面记录并提供足够的开发人员支持。
检查配置并避免配置错误：确保正确的配置是确保您的环境安全的第一道防线。
确保您的版本控制良好：在 API 的生命周期内管理重大更改和版本控制，确保用户持续受到支持。
采用适当的安全态势，例如最小特权：确保您遵守基本的常识性安全解决方案来保护整个平台的安全。
正确实施网关、负载均衡器和其他解决方案：利用成熟的技术平衡和统一您的 API 流，确保您的环境正确分布且健康。

市场实例

让我们来看看这些模型的一些具体示例。我们将展示一些同步和异步 API 样式的真实示例，以便您了解它们的区别。

同步 API 示例

同步 API 的一个典型示例是Google Geocoding API。此 API 允许您将地址、一组坐标或地点 ID 发送到内部服务器，然后服务器将其转换为任何其他形式。例如，您可以提交一组坐标并获取地址和地点 ID，或者您可以提交地点 ID 并获取地址和一组坐标。API 会立即响应请求，从而允许在各种数据形式之间快速转换。提供商在收集不同的位置信息并将其标准化为一组时可能会发现这很有用。