服务导向架构是一种架构方法学。它是一种从业务角度分离责任的方式，将其分为独立的服务，并通过公共 API 进行通信（通常但不一定通过将事件发布到总线上）。
例如，您可以有一个负责捕获客户订单的服务，它将 OrderCaptured 事件发布到总线; 以及一个单独的服务，负责跟踪客户何时结账以及欠款金额，该服务订阅总线并响应 OrderCaptured 事件。由于分离了职责，第一个服务可能不需要了解任何关于计费的信息。 而且这两个服务也不需要相互了解，只需要了解周围发生的事件即可。
API 是组件/服务提供的接口，以便其他组件可以与其通信。在上面的示例中，总线为多个服务提供了一个通用的 API。
简而言之：
API=软件组件公开的任何通信方式。
SOA=一组企业体系结构设计原则，通过将责任拆分为服务来解决可扩展性问题。
3
换句话说：
SOA是架构模式。
API是实施或启用SOA模式的其中一种方式。
SOA是“规划”{蓝图}设计方法。
API是设计的实际实现。
1
简明扼要版：
API 是一种通过http、web sockets等方式提供数据访问的层，更适合移动端使用。这些API应该考虑到SOA的支持架构，并且目前使用围绕JSON和REST的现代技术。
SOA 是更多面向A2A和B2B业务解决方案的层，在业务需要在不同类型的媒介之间传递数据时，会建立API并围绕其建立业务规则。技术通常是XML、RPC和SOAP。
两者都使用可互换的技术。如果其目的是提供开放数据，则安全性可以在两者中进行处理，但SOA通常更为重视。
看起来对此有很多不同的意见，这是一个有趣的阅读。以下是我的看法。
SOA：SOA是一种以服务为中心的架构模式，用于构建和访问软件组件/服务套件（如上面的答案所指出的）。形成SOA模式的SOA原则可以在许多地方找到，其中并非所有地方都是一致的，使得SOA成为一个有些模糊的术语。几乎可以使用任何现代软件开发技术集（见下文）来构建SOA服务。
API：通常，“API”一词用于表示如何以编程方式利用或与软件解决方案进行接口。它可以指诸如编程语言及其组件的规范（Java API）、如何访问和/或扩展COTS解决方案的规范、如何利用一项服务或一组服务的规范（包括与服务接口相关的签名或数据结构）等。
SOA和API：用于SOA服务的API可以包括服务的概念性、技术无关的规范（例如：一个数据元素将是客户的姓氏），以及每个物理实例的物理、技术特定使用规范（例如：两个实例可用，一个使用JSON布局，另一个使用XML布局，每个布局都包含大致等效的“LAST NAME”数据元素的物理规范）。
误解：术语API只应用于RESTful或“简单、轻量级”的基于JSON的接口（副注：RESTful不等同于“简单”或“轻量级”）。实际上，API可以遵循许多模式，使用许多类型的技术进行结构化，包括基于WS*的服务。
误解：SOA严格遵循WS*或其他“复杂、重量级”的接口方法。实际上，SOA服务可以使用几乎任何现代软件开发技术集进行构建和消费，包括RESTful方法或JSON文件。
关于SOA的更多内容： SOA是建立在能力应该被实例化为服务的概念之上的架构模式，这些服务具有清晰的使用规范，因此可以被任何遵循该使用规范的软件组件“客户端”利用，而不管服务是基于哪种技术开发的或者“调用客户端”是基于哪种技术开发的。编写良好的服务应该具有高度的跨兼容性。由于许多开源提供商和供应商已经构建了基于XML的SOA导向框架，特别是WS*一系列标准，因此有时会错误地将SOA与WS*和/或XML相关方法限制性地联系起来。但实际上，作为一个概念模式，SOA是技术中立的。一个概念上的SOA服务可以以多种形式实例化一次或多次，每个实例化都可以选择从各种技术（XML、JSON、WS*、REST方法、Java、C++、LAMP等）中选择，由该实例化的设计师和开发人员决定。
SOA解决方案或解决方案生态系统是基于SOA原则构建的，它由按照SOA原则构建和使用的服务组成，再次使用开发人员选择的任何技术。
原文链接