api什么意思(网页调用api接口)

应用程序编程接口向开发人员隐藏复杂性，将系统扩展到合作伙伴，组织代码并使组件可重用

API 代表应用程序编程接口，这个概念适用于从命令行工具到企业 Java 代码再到 Ruby on Rails Web 应用程序的任何地方。API 是一种以编程方式与单独的软件组件或资源进行交互的方式。

除非你从头开始编写每一行代码，否则你将与外部软件组件交互，每个组件都有自己的 API。即使你完全从头开始编写一些东西，设计良好的软件应用程序也将具有内部 API 来帮助组织代码并使组件更可重用。并且有许多公共 API 允许你利用通过网络在其他地方开发的功能。

什么是 API？

API 被定义为与软件组件可能交互的规范。这究竟是什么意思？好吧，想象一下汽车是一个软件组件。它的 API 将包括关于它可以做什么的信息——加速、刹车、打开收音机等。它还包括关于如何让它做这些事情的信息。例如，要加速，您将脚放在油门踏板上并推动。

API 不必解释当你踩下油门时发动机内部会发生什么。这就是为什么，如果你学会了驾驶内燃机汽车，你就可以驾驭电动汽车，而无需学习一套全新的技能。API定义中的内容和方式信息结合在一起，该定义是抽象的并且与汽车本身分离。

要记住的一件事是，某些 API 的名称通常用于指代交互规范和与你交互的实际软件组件。例如，短语“Twitter API”不仅指以编程方式与 Twitter 交互的一组规则，而且通常被理解为表示您与之交互的事物，如“我们正在对我们从中获得的推文进行分析” Twitter API。”

API 作为抽象层

说到软件，API 几乎无处不在。API 与计算机科学中最基本的概念之一密切相关：抽象。抽象只是组织系统复杂性的一种方式，以便可以以简单的方式处理复杂的操作。把这种抽象想象成那些淘宝 Dash Buttons，电池供电的按钮电路板，你可以用来从淘宝订购订书钉。这是它们的样子：

你从淘宝订购了一个 Dash Button，并使用智能手机上的应用程序将其与你的 Wi-Fi 网络、你的淘宝帐户和产品（例如你最喜欢的纸巾品牌）相关联。然后，每当你想订购更多纸巾时，只需按下按钮即可。Dash Button 连接到 Internet 并发送消息以在你的帐户上下订单。几天后，纸巾就会送到你家门口。

像 API 一样，Dash Button 是一个非常简单的界面，在幕后隐藏了各种复杂性。你订购的产品的 ID 必须从某个数据库中检索。你的送货地址必须从你的帐户中提取。必须确定最近存放你的纸巾的运营中心，然后通知你从可用库存中移除商品并打包。最后，包裹必须与其他包裹一起通过飞机、卡车和货车的某种组合，以确保所有包裹都能有效地到达目的地。

现在想象一下，作为客户，你必须协调所有这些事情。你永远不会订购纸巾，因为它太复杂和耗时，而且你还有更好的事情要做。幸运的是，整个磨难都离你而去。有一条长长的、相互关联的计算机系统和人工流程链让这些纸巾出现在您家门口，但你只需按下一个按钮即可。

这就是 API 对程序员的意义。它们采用了大量的复杂性，并定义了一组相对简单的交互，您可以利用这些交互，而不是自己全部完成。在任何软件项目中，你可能会直接使用数十个甚至数百个 API，并且这些 API 中的每一个都依赖于其他 API，依此类推。

公共 API 和 API 集成

API 是计算机编程中的一个长期概念，多年来它们一直是开发人员工具集的一部分。传统上，API 用于连接在同一台机器上运行的代码组件。随着无处不在的网络的兴起，越来越多的公共 API（有时称为开放 API）变得可用。公共 API面向外部并可通过 Internet 访问，允许你编写与其他供应商在线代码交互的代码；此过程称为API 集成。**

这些类型的代码混搭允许用户在他们自己的系统上混合和匹配来自不同供应商的功能。例如，如果你使用营销自动化软件 Marketo，你可以将你的数据与 Salesforce CRM 功能同步。

在这种情况下，“开放”或“公共”不应被解释为“免费”。你仍然需要成为 Marketo 和 Salesforce 客户才能使用此功能。但是这些 API 的可用性使集成过程比其他方式简单得多。（InfoWorld有很多您应该了解的公共 API 列表*。）

Web 服务和 API

你可能会想起00 年代早期的网络服务一词，并认为开放 API 的想法听起来非常相似。事实上，Web 服务是一种特定类型的开放 API，它满足一组相当严格的规范，包括用 Web 服务描述语言 (WSDL)（一种 XML 变体）指定的规范。

Web 服务旨在用作面向服务架构 (SOA) 的一部分。正如Nordic APIs 博客所解释的那样，这给 Web 服务带来了坏名声，因为 SOA 从未完全发挥其潜力。用于服务到服务通信的技术的进步——特别是更轻量、更灵活的 REST——也让 Web 服务在公共 API 的世界中有些落后。

REST API

Web 服务最初设计为使用 SOAP（简单对象访问协议）进行通信，这是一种通过 HTTP 发送 XML 文档的消息传递协议。然而，如今，大多数基于 Web 的 API 都使用 REST（具象状态传输）作为架构风格。

REST 由Roy Fielding 在2000 年的博士论文中正式引入。它是一组架构组件、设计原则和交互，用于构建涉及任何类型媒体（文本、视频等）的分布式系统。从本质上讲，REST 是一种构建系统的风格，它允许在网络上灵活地通信和显示信息，同时提供轻松构建通用组件所需的结构。

在 REST API 中，资源几乎可以是任何东西，但示例包括用户、推文列表和推文搜索的当前结果。这些资源中的每一个都可以在资源标识符处进行寻址，在基于 Web 的 REST API 的情况下，该标识符通常是一个 URL。当应用程序使用标识符请求资源时，API以应用程序可以使用的格式（例如 JPEG 图像、HTML 页面或 JSON）将该资源的当前表示交付给应用程序。

REST 的一大区别在于它涉及向发出请求的应用程序发送数据。虽然这提供了极大的灵活性，允许应用程序对数据做任何它想做的事情，但它是以效率为代价的。与在数据所在的位置进行处理然后发送结果相比，通过 Web 发送数据进行处理要慢得多。

当然，“高效”方法的问题在于托管数据的系统需要提前知道应用程序想要用它做什么。因此，为了构建具有通用可用性和灵活性的 API，REST 是必经之路。

API 示例

有许多公共 API 可供您交互，其中许多来自行业巨头。通过 API 以编程方式访问某些平台公司代码的能力使它们成为一个平台，本质上。一些突出的 API 示例包括：