您想将您的应用程序链接到 Facebook 以便它可以自动生成帖子,还是链接到 Instagram 以便您可以重新发布带有特定主题标签的照片?
您可能还希望在您的网站上包含 YouTube 视频。 应用程序编程接口允许您执行所有这些任务以及更多 (API)。
借助 Instagram API、Facebook API 和 YouTube API 等 API,不同的应用程序可以以安全和标准化的方式相互“对话”。
换句话说,一个程序可以从另一个软件中获取特性或数据,并利用它们来改进它自己的特性或用户体验。 但是应用程序如何以其他人可以理解的方式提出这些请求、处理它们并响应它们呢?
这取决于 API 的创建方式。 在讨论 API(应用程序编程接口)设计时,通常会比较 SOAP 与 REST,这两种最突出的 API 范例。
一旦 SOAP API(简单对象访问协议)成为 Oracle、Sun 和 PayPal 等公司的黄金标准,大约一年后,Google、Amazon 和 eBay 对 REST API 的反应是相同和相反的。
在这篇文章中,我们将比较 SOAP API 和 REST API,以便您决定哪种方式最适合您的目的。
我们将从定义 API 开始。
什么是API?
应用程序编程接口称为 API。 API 本质上是支持应用程序开发的方法和函数的集合。 他们可以访问不同程序、服务或操作系统的信息和功能。
它们充当各种软件系统之间的一种中间人。 它们使两个未连接的程序之间能够“交谈”。
让我们以积极参与交易和金融市场的股票经纪人为例。 自动化集合 交易算法 可以通过API连接到交易者最喜欢的交易经纪平台。 这使您(交易者)能够执行电子交易或查看实时报价和定价数据。
什么是休息?
真正的“Web 服务”API 包括 REST(具象状态传输)。 REST API 建立在 URI(统一资源标识符,其中 URL 是一种特殊类型)、HTTP 协议和令人难以置信的与浏览器兼容的 JSON 数据格式之上。
正如我们已经说过的,SOAP 协议也可能被使用。 REST API 可以很容易地创建和扩展,但它们也可能非常庞大和困难——这完全取决于它们的创建、扩展方式以及它们的用途。
资源限制、安全要求降低、浏览器客户端兼容性、可发现性、数据健康和可伸缩性是您希望开发 API 为 RESTful 的一些原因——这些东西实际上适用于 Web 服务。
REST 提供了一个更轻量级的选项。 SOAP 对许多开发人员来说难以使用和繁重。 例如,将 SOAP 与 JavaScript 一起使用需要编写大量代码来完成简单的操作,因为每次都必须创建必要的 XML 结构。
REST(通常)使用简单的 URL 代替 XML 请求。 尽管在极少数情况下您必须提供更多详细信息,但大多数 RESTful Web 服务仅使用 URL 技术。
REST 可以使用四个 HTTP 1.1 动词 GET、POST、PUT 和 DELETE 来执行操作。 与 SOAP 不同,REST 不需要答案是 XML。
基于 REST 的 Web 服务以命令分隔值 (CSV)、JavaScript 对象表示法 (JSON) 和真正简单的聚合 (RSS) 格式 (RSS) 输出数据。
目标是您可以在您用于应用程序的语言中以易于解析的格式获得所需的结果。
特征
- 由于 HTTP 协议,REST 强调简单性高于一切。
- Web 最适合 REST。 它与浏览器兼容,因为使用 JSON 作为数据格式。
- REST 以其出色的可扩展性和速度而闻名。
- REST API 使客户端-服务器连接和架构更易于访问。 如果它是 RESTful 的,它是使用这种客户端-服务器模型构建的,在两方之间进行往返传递数据有效负载。
- REST API 使用单独的标准接口。 确保所有应用程序通过同一网关统一连接,简化应用程序与 API 的通信方式。
什么是肥皂?
它自己的协议称为 SOAP(简单对象访问协议),比 REST 稍微复杂一些,因为它指定了更多标准,包括与安全性和消息传递相关的标准。
这些固有的规范确实带来了一些额外的开销。 但是,对于需要更广泛的安全性、事务和 ACID(原子性、一致性、隔离性、持久性)合规性能力的企业来说,它们可能是一个决定性因素。
为了进行比较,重要的是要注意 SOAP 的许多好处通常不适用于 Web 服务应用程序,这使得它们更适合企业类型的场景。
更高程度的安全性(例如当一个 移动应用程序 与银行交互)、需要可靠通信的消息传递应用程序、与遗留系统交互或 ACID 合规性是您希望使用 SOAP API 设计应用程序的几个原因。
SOAP 提供的消息传递功能完全基于 XML。 旧的 Internet 不兼容技术,如分布式组件对象模型 (DCOM) 和通用对象请求代理体系结构,在 Microsoft (CORBA) 首次创建时被 SOAP 取代。
对二进制通信的依赖导致这些系统失败。 在 Internet 上,像 SOAP 使用的 XML 消息传递功能更好。
特征
- SOAP 的安全性要严格得多。 WS-Security 是一种内置标准,如果需要,除了 SSL 支持之外,它还提供 SOAP 额外的企业级安全功能。
- 值得信赖的消息传递性能的成功/重试推理。 因为 REST 缺乏标准化的消息机制,所以只能在通信失败时重试。 即使在使用 SOAP 中间体时,由于其内置的成功/重试逻辑,SOAP 也提供了端到端的可靠性。
- SOAP 已经符合 ACID 标准。 通过规定事务如何与数据库交互,ACID 合规性可以最大限度地减少异常并保护数据库的一致性。 由于 ACID 比其他数据一致性模型更谨慎,因此在管理敏感事务时经常使用它,无论是财务还是其他方面。
- 由于 SOAP 是完全基于 XML 的通信,因此程序员很容易理解。
- XML 消息传递协议是对 HTTP 协议的补充。
- 从一台计算机到另一台计算机的通信可以通过 SOAP 消息传递。
- 也可以实现客户端-服务器架构。 客户端可以使用 SOAP 协议消息来调用位于服务器端的远程过程调用。
REST 与 SOAP 的区别
1。 架构
API 旨在主要显示服务器上应用程序业务逻辑的特定组件。 虽然 REST 出于相同目的使用 URI,但 SOAP 为此使用了服务接口。
REST API 是在数据之后创建的,而 SOAP API 是在 API 说明的功能之后开发的。 与更受功能驱动的 SOAP 相比,REST 是更受数据驱动的设计。
2。 高速缓存
被标记为可缓存的数据可以被浏览器再次使用,而不需要它们向服务器发出新的请求。 节省时间和精力是这样做的好处。
响应不会在 HTTP 级别缓存,因为 SOAP 查询是通过 POST 请求提交的,HTTP 标准认为这是非幂等的。 如果您想使用缓存,您仍然必须构建必要的技术,因为 REST API 不包含此实现。
3. 资源和带宽
由于 SOAP 使用信封式有效负载传输,开销会适度增加,这需要额外的带宽。 REST 的轻量级特性在这些情况下是一个优势,因为它通常用于 Web 服务。
4. 安全性
SOAP 支持的 WS-security 是可取的,它在传输级别上比 SSL 稍微彻底一些。 将企业级安全措施与它结合起来也是一个完美的选择。
SOAP 和 REST 都支持使用 SSL 的端到端加密,并且 REST 可以使用 HTTPS(HTTP 协议的安全变体)。
5. 处理有效载荷
通过 Internet 传输的数据称为有效载荷。 被认为“重”的有效负载需要额外的资源。 与使用 XML 的 SOAP 相比,REST 经常使用 JSON 和 HTTP 来帮助减少负载。
客户端通常必须使用带有生成代码的专用客户端库来访问 SOAP API,因为它们的通信合同极其严格。
因此,SOAP 提供的抽象级别比 REST 低,并且与服务器的连接更紧密。
何时使用 REST?
- 创建公共 API: REST API 是构建公共 Web 服务的首选,因为它们被认为比 SOAP API 更易于使用和采用。 此外,SOAP 提供了一些 REST 所没有的内置安全措施,尽管在处理开放数据和服务时不需要这些特性。
- 构建移动应用程序: REST 非常适合构建移动应用程序,因为它小巧、有效、无状态且可缓存。
- 利用稀缺的服务器资源和带宽:对 REST API 的所有请求都必须是无状态的,这意味着每个交互都是独立的,每个请求和响应都包含完成该交互所需的所有数据。 服务器不会保存先前请求的记录,因为它将每个请求都视为新请求。 因此,服务器需要更少的内存并且运行得更快,因为请求不需要进一步的操作或检索历史数据。
何时使用 SOAP?
- 创建私有 API,尤其是对于大型企业:SOAP 非常适合企业应用程序,因为它支持分散的分布式环境中的数据流,并包含多个在线安全功能。
- 使用 HTTP 以外的传输协议作为底层: SOAP 不依赖 HTTP 作为底层。 根据您的应用程序,您可以使用 SMTP(简单邮件传输协议)、JMS(Java 消息服务)或其他传输协议。
- 使用有状态操作:与对 REST API 的请求相比,对 SOAP API 的请求是有状态的,这意味着服务器保存有关客户端的信息并在请求或操作链中使用它。 尽管这会使用更多的服务器带宽和资源,但它对于执行常规或链接操作(如银行转账)至关重要。
结论
REST 和 SOAP API 之间的比较表明 REST 比 SOAP 更可取。 即便如此,也有需要 SOAP API 的情况。 在某些情况下,Web 服务是通过结合 REST 和 SOAP API 创建的。
因此,用例将决定哪种 API 风格效果最好。
发表评论