想了解更多关于这个经典 API 架构的信息，即使是 REST 的粉丝？
让我们通过 Tipsmake 找出 SOAP 是什么，看看它今天是否还在使用！
什么是 SOAP API？它是如何工作的？
SOAP 基于 WSDL（Web 服务描述语言），这是一种用于在软件之间发送数据的可扩展标记语言 (XML)。
考虑到 XML 的刚性结构，SOAP API 传输的数据非常冗长，而且似乎比更流行的 REST（REpresentational State Transfer）架构更复杂。
从 SOAP API 发送或接收数据意味着您正在传输包含在各个标识标签中的紧密封装的项目。 SOAP 中的数据排列在专用文件中遵循严格的结构和访问模式。这使得 SOAP 高度面向协议。
除了通过 HTTP（超文本传输协议）传输数据外，SOAP 还支持更原始的协议，包括 FTP（文件传输协议）、TCP（传输控制协议）和 SMTP（简单邮件传输协议）。因此，它为跨许多不同网络和平台的传输提供了灵活性。
也就是说，虽然其他传输协议可以交换原始数据，但通过 HTTPS 网络提供 SOAP 服务更可行.
SOAP 使用 Web 服务 (WS) 的安全性，这是一种专用的消息加密扩展。因此，这填补了使用 HTTPS 以外的数据传输协议发送数据的空白。
这还与 SSL（安全套接字层）结合使用，后者是一种通过 HTTPS 为网站提供服务的安全令牌。因此，在安全性方面，SOAP 比 REST 有优势，后者仅依赖 HTTPS 来保证安全性。
此外，SOAP API 返回的数据格式是预先编程的。这使得跨多种编程技术轻松集成成为可能。
因此，SOAP API 是可扩展的、跨平台兼容的且与协议无关。
SOAP 架构
SOAP 与任何 API 框架一样，具有共同的结构。也就是说，SOAP API 的架构类似于 HTML DOM。
SOAP API 具有以下结构：
- 信封：这告诉您传入或传出的 XML 是 SOAP 数据。您可以将其视为 HTML DOM 中的头部。
- Header：它包含更多的 XML 标题信息。
- 正文：这是 SOAP 消息的负载或正文。
- 故障：SOAP API 中的错误处理和请求状态。
今天是否仍在使用 SOAP API？为什么？
最初由 Microsoft 于 1998 年设计和使用，SOAP 被认为是古老而复杂的。它已在很大程度上被更灵活的 REST 架构所取代，该架构为当今 70% 以上的公共 API 提供服务。
然而，一些领先的公司仍然使用 SOAP-特别是作为内部服务之间传输的中间人。
SOAP API 支持无状态和有状态通信。这种可组合性是 SOAP 在某些情况下仍然是首选框架的另一个原因。
当您在状态数据交换中使用 SOAP 时，它可以跨多个请求实现高效的信息跟踪。虽然这种复杂的操作可能会阻塞服务器，但在构建需要额外安全和链接层的复杂应用程序时，它仍然使 SOAP 成为首选。
另一方面，无状态转换不会使服务器的内存过载。因此，如果旨在减少运行时间并获得更好的服务器性能，此功能同样方便。
但现在 Web 服务不再使用 SOAP 来处理无状态通信，而是更喜欢使用 REST 框架，该框架更加灵活且完全无状态。
例如，Microsoft Dynamics 程序使用 SOAP API 来提供业务面向大公司的企业解决方案。
因为 SOAP 符合 ACID、有状态、提供 WS 安全加密并带有 SSL，所以它是一种用于银行和金融应用交易的流行 API 架构。
SOAP API 的有状态特性在事务期间保持数据库的完整性。即使请求失败，它也会跟踪和逆转es 泄露的数据。
这解释了遵守 ACID（原子性、一致性、完整性和持久性）概念的含义：
- 原子性：指定请求中每个进程的相关性。这样一来，单个请求单元的失败就会使整个流程脱轨。
- 一致性：确保数据库查询和方法遵循定义的规则。
- 完整性：即使请求并发发生，也能保持数据库的状态。
- 持久性：即使服务器出现故障，也将成功的请求保持在其状态。
是否应该在程序中使用 SOAP API？
SOAP 作为软件之间最安全的消息传递渠道之一在 API 领域占据主导地位。尽管复杂、缓慢、陈旧且笨重，但今天的许多公司仍然离不开 SOAP。虽然现代 API 易于使用，但毕竟 SOAP API 在某些情况下可能是最佳选择。
除了自己创建解决方案之外，您可能会发现自己处于一种可以在软件中提供解决方案的唯一适用选项。因此，更多地了解 SOAP 可以增加有关 API 的宝贵知识。
0 评论