API 设计是一个令人着迷的话题。API 设计的一个重要方面是根据 API 的特性和功能确定正确的“大小”。所有建筑师都必须在某个时候解决过这个问题。在本文中，我将尝试对我们在获得“正确的”粒度 API 之前需要考虑的各种参数进行一些深入的探讨：

可维护性： 首先想到的是 API 的可维护性。粗粒度的 API 很难维护。随着 API 使用者需求的增长，添加更多的实现变体或参数将变得困难。

管理：在MuleSoft中，我们可以使用API​​ Manager来单独管理每个API。这意味着我们可以根据需要对每个 API 实施 IP 白名单、IP 黑名单、基于 SLA 的速率限制、JSON 威胁防护等安全策略。由于每个安全策略都会增加一点延迟，因此这成为一个重要的考虑因素。 

错误处理： 您可以在不同的 API 中应用更清晰的错误处理。这也可能导致为不同的 API 定义 MuleSoft 警报

可部署性：细粒度的 API 易于部署。如果正确遵循版本控制，我们可以快速部署较小的 API，并以更敏捷的方式向市场推出功能。这通常会缩短创新周期，因为更改和新功能可以更快地部署到生产中

可扩展性：Cloudhub工作线程独立分配给每个API实现，因此可以根据每个API实现的特定需求进行调整（缩放）

资源：每个 API 实现无论有多小，都会消耗最少的一组资源（CloudHub 工作线程），而更多的 API 实现（即使它们更小）通常
意味着总体资源使用量更高

复杂性：较小的 API 和 API 实现更简单，因此更容易理解和维护。与更大且更少的 API 和 API 实现相比，它们还会导致应用程序网络中可见更多与 API 相关的资产以及越来越复杂的交互（API 调用）。然而，由于这些 API 之间的交互，具有许多细粒度 API 的大型系统将非常复杂

延迟：每个额外的 API 调用至少会增加少量延迟，因此较小的 API 会导致较高的总体延迟，通常必须通过缓存等来缓解。对于体验 API，请仔细考虑此参数。移动订单 API 比基于 Web 的订单 API 对延迟更加敏感。

故障模式：每个额外的 API 调用都是应用程序组件之间的额外远程交互
，必须解决其潜在故障。另一方面，粗粒度的 API 可能会成为单点故障。

组织结构：在任何大型组织中，不同的业务线如果具有不同的限界上下文，则必须相互交互。通过细粒度 API，每个 API 都可以独立于所有其他 API 实现而实现，前提是 API 实现之间的应用程序接口（以 API 规范的形式）已达成一致。这意味着通过细粒度的 API 和 API 实现，团队组织和实现工作的并行化将更加灵活。

重要的是要记住，这两种方法的整体功能保持不变，但最终使用细粒度 API 方法会获得更多的端点。作为开发人员，您可以放心，您的代码将更加结构化，因为每个 API 对应不同的操作。在大多数情况下，您都需要这两种 API。