让我们首先看看API，它似乎是最主要的选择：
API
API定义了允许两个应用程序相互通信的契约。这种契约的形式是服务器承诺提供的协议和样式，而客户应该遵守。
API一种主要风格是REST，它在这种面向服务的架构中取代了SOAP，如今已经很普遍了。虽然它有局限性，但通常被认为是自然适合我们的HTTP文化。
值得一提的是，远程程序调用（RPC）是一种协议，使客户能够在远程服务器上调用一个函数--一个程序--就像它在本地可用一样。客户端代码从网络细节中抽象出来，因为该协议负责处理远程调用。
信息传递
通过信息传递，我们将概念从客户/服务器对转移到生产者/消费者。
虽然这听起来像是 "没有区别的区别"，但我们有两个要点要强调：
1、它提供了时间上的解耦
消息传递在本质上是异步的，正在发送（或发布）的消息的生产者并不等待它被消费者接收、确认和处理。
2、它支持一对多的语义
被发送的消息如果是一个事件，我们有一个潜在的一对多的能力，对于这个单一的消息，许多不同的消费者可能对它感兴趣。
这两者结合在一起，使你的应用程序能够处理你的依赖关系中的临时中断，以更优雅的方式处理需求的高峰，或者在不修改发送者的情况下扩展功能。
另一个好处是，如果你的应用程序必须处理时间的流逝，你可以使用消息传递来更好地捕捉你的领域需求。
为你选择正确的服务调用方式
如果你面临开发一项新的服务，或者有机会重新审视现有的服务，我建议你看一下以下标准，根据你的实际情况尝试评估每一项。
1、 团队知识和工具
信息传递是一个强大的选择，但正如我们所看到的，它有一些挑战，因为它与许多人可能习惯的线性模式不同。我不知道你的情况，但我的第一次经历都是在同步模式下，无论是API还是RPC。
如果你的团队之前没有使用消息传递的经验，那么在功能需求的基础上，挑选它就会带来额外的挑战。
如果是这样的话，我建议在你的项目估算中至少要保证有额外的时间进行实验和学习。如果你不能保证这一点，请理解，由于未知因素，有更高的风险，API路径将是一个更好（或更安全）的选择，至少现在是这样。
消息传递的许多问题只有在较高的规模下才会表现出来，所以在开发或常规测试中，你可能认为一切都很顺利，但一旦上线就会发现问题。
2、你是否需要一个同步响应
这是个 "简单 "的问题。如果你的应用程序需要在能够继续进行之前从一个给定的请求中得到答案，并且你有一个时间敏感的案例--例如，一个用户在用户界面上等待--API是你的选择。
虽然有可能启动一个异步流程和一个轮询或WebSockets解决方案来提供反馈，但这些都会带来额外的复杂性，你应该评估是否真的值得这样做的成本。
注意不要以为同步方式永远是这样的。这可能只是当前实践的结果。
3、你有长期运行的执行吗？
如果你需要到达的服务可能有很长的执行时间，客户端将处于等待模式，持有资源，如内存和TCP/IP套接字。在小规模的情况下，这可能可以忽略不计，但随着需求的增加，你将会求得这些资源。
4、你是否有许多（非关键的）依赖性
根据你的生态系统的颗粒度，你可能会发现自己在执行一个特定用例的过程中会遇到许多依赖关系。
虽然这本身可能是存在Bug的标志，总的来说：有许多依赖关系意味着你必然要处理其中任何一个的潜在故障。
结论
在开发新的服务时，使用API或Messaging进行整合是你将面临的共同决定。
正如我们看到的，这个问题没有简单的答案，因为在大多数情况下，两者都能以类似的方式解决你的连接需求。
我提出了一些启发式方法来帮助你做决定。但请记住，它们几乎不是唯一的因素，其中一些因素本质上是主观的，如团队的专业知识或引入新技术的风险。