API 是现代 Web 应用程序设计的基础部分。它们允许您通过一个 Web 浏览器访问来自许多不同公司和来源的服务。许多人与 API 交互，甚至没有意识到这一点，例如网站上的“使用 Facebook 登录”按钮或使用移动相机的应用程序。

这是我们今天要介绍的内容：

• 什么是 API？
• API 的好处
• API 的类型
• 接下来要学什么

什么是 API？

API 代表应用程序编程接口，充当两个系统之间的稳定中介。正如用户界面 (UI) 将用户连接到系统一样，API 将一个系统连接到另一个系统或一个软件组件连接到另一个系统。大多数 API 被称为**Web API，**因为它们将网页链接到其他应用程序或数据库。

API 通常被视为餐厅中的服务员，客户是一个系统，厨房是另一个系统。

服务员 API 告诉客户哪些服务可用，可以将请求中继到厨房，并可以访问限制信息，例如订单在队列中的位置。客户不需要知道这家餐厅如何运作或他们的订单如何处理的细节，而是可以简单地placeOrder相信服务员 API 会翻译它以适应他们的后端厨房系统。

由此，我们可以看到 API 提供了一个抽象层，允许其他系统发出 API 请求或调用，而无需访问后端细节。

例如，操作系统具有允许开发人员更改按钮外观的 API。开发人员不需要知道用户拥有什么类型的系统或手动编码使其成为按钮的行为。相反，他们可以简单地要求 API 呈现一个按钮，API 会将该调用转换为操作系统能够理解的术语。

这种抽象对开发人员来说非常有用，因为这意味着他们可以为稳定的 API 设计他们的产品，而不必担心为每个系统手动实现该功能，或者如果后端系统发生变化，他们的应用程序会中断。

开发人员经常使用不同类型的 API 来使他们的应用程序与外部技术有更多的联系。

例如，Facebook API 可能允许用户从他们的健身应用程序分享目标，或者 Stripe API 可能允许应用程序利用受信任的第三方交易服务来完成购买。

总体而言，API 增加了我们设备之间的连接性，并允许开发人员更多地关注设计而不是实现。

API 的好处

抽象并不是 API 提供的唯一好处。让我们来探讨一下您可以通过使用获得的一些最佳好处

外用

如果您的应用变得流行，其他技术可能会要求 API 与您的系统进行交互。因此，您基本上会收到免费宣传，并最终获得用户，因为它会将您的产品介绍给新的用户群。

例如，Web 应用程序可能包含一个“通过亚马逊购买”按钮，以便为客户提供一个简单的下一步。这改善了应用程序用户的客户体验。与此同时，亚马逊受益，因为它在用户每次登录时都会向他们展示他们的品牌，即使是在非亚马逊应用程序上。

安全

由于 API 充当系统之间的缓冲区，它们允许您选择允许和不允许的行为。用户可以根据自己的隐私偏好做出更个性化的选择，而不是全有或全无。

例如，您可能希望使用应用程序的 Twitter API 集成在社交媒体上发布图片，但不希望该应用程序知道您的位置。使用 API，您可以使用一项服务（帖子）而不会自动允许另一项服务（位置共享）。由于有一定数量的 API 可以访问移动位置，因此操作系统很容易识别何时尝试并请求用户批准。此选择将使您的最终用户更舒适，并使他们的体验更好。

更快的生产

API 使程序员可以更轻松地快速构建应用程序，因为它们简化了他们必须考虑的设备数量，并允许他们导入外部 API 以添加某些关键功能。例如，您可以创建一个应用程序，让用户可以找到他们所在地区新晋艺术家的活动。

这些开发人员的主要兴趣应该是确保事件创建系统运行良好，并且用户可以轻松浏览结果。虽然他们仍然需要地图和销售系统，但他们可以使用合作伙伴 API（例如Google Maps API）来呈现准确的地图，并使用 Salesforce eCommerce API 来处理销售。

自动化

API 对于自动化测试也非常有用。以前，测试人员必须依靠自定义脚本、外部 Web 服务和直接集成来处理他们的测试需求。虽然这适用于小规模，但直接集成使测试环境在处理不同工具时变得不灵活，并且仅限于少量测试。API 提供的抽象允许测试人员在 XML 或 JSON 文件中创建通用测试套件，并在与其 API 集成的任何系统上使用它们。

API 的类型

API 由三个因素分类：谁应该使用它们，它们使用什么协议，以及它们如何与系统的其他方面集成。了解这些类型将有助于您使用 API、指导API 设计，甚至在当前的 API 管理期间。我们将查看每个不同的 API 示例以了解每种类型之间的差异。

发布政策

API 允许对集成它们的任何人进行一定程度的访问，但是我们不想为消费者提供与对企业客户或其他内部团队相同的访问权限。因此，我们制定了发布政策，用于定义 API 授予系统的访问权限。

访问分为三层：私有 API、合作伙伴 API 和公共 API。

• 私有 API是仅在公司内部使用的内部 API。它们提供最高级别的访问权限，并允许同一工作生态系统中的人员访问数据、编辑功能，并根据需要查看某些后端复杂性。

  私有 API 非常适合像 Microsoft 这样被分成许多不同团队的大型软件开发公司，因为它允许所有团队访问一组标准的 Web 服务。

• 合作伙伴 API与选定的业务合作伙伴共享，以允许经批准的用户访问 API。例如，eBay 可以使用合作伙伴 API 系统允许经过审查的供应商从他们的列表中购物，但低质量或不安全的供应商不能。

  这允许应用程序开发人员通过仅允许高标准应用程序使用其 API 来执行质量控制标准并保持较高的品牌声誉。

• 公共 API，有时称为“开放 API”，可供公众以与开源软件类似的格式使用。大多数平台 API（如 Microsoft 或 Apple 的 API Cocoa）都是公开的，以允许开发人员轻松地在他们的平台上制作应用程序。

API 协议

协议是一组标准化规则，用于定义应如何构建 API，以便更轻松地以一致的格式快速实施新 API。

• **REST API**代表具象状态传输。它主要用于在 Web 服务中共享文档。REST 应用程序旨在优先考虑组件的可扩展性和接口的简单性。

  为此，REST 规则规定您只能使用 CRUD 函数，而不管命令的复杂程度如何。这意味着REST应用程序使用简单的HTTP方法，如GET，POST，DELETE，和PUT。虽然忽略部分工具似乎有悖常理，但它最终会迫使您用简单、可扩展的术语来描述复杂的行为。

• RPC代表远程过程调用，旨在对服务器方法进行 API 调用，而不是共享文档。换句话说，REST API 侧重于从服务器拉取资源以在客户端执行操作，而 RPC 侧重于发送操作请求以供服务器执行。这会带来更一致的体验，但没有那么可扩展。

  RPC 是一种较旧的协议风格，在很大程度上被 REST API 所忽视。

• SOAP是简单对象访问协议的首字母缩写词。它是一种标准通信协议，允许跨不同操作系统进行通信。它主要用于创建、更新和从共享数据库中提取数据。

  SOAP 旨在通过支持所有主要操作系统和 Web 服务编程语言（例如 Python、JavaScript 和 Java）来优先考虑多功能性。

API架构风格

应用程序架构是指导系统结构和流程的规则和设计原则。协议是系统架构的一个方面。如果协议是微观 API 消息传递的规则，那么架构就是一切如何组合在一起的宏观计划。

有两种主要的架构类型在 Web 服务领域占据主导地位：

• **面向服务的体系结构 (SOA)**是两种体系结构中较旧的一种。与以前处理一切的单体应用程序不同，SOA 应用程序将一些功能外包给不同的应用程序，这些应用程序都通过集成模式松散耦合。

  虽然 SOA 解决了单体结构的许多问题，但如果其他耦合应用程序更新，缺乏集中控制可能会引入复杂性。

• **微服务架构**是 SOA 的迭代。它保持松散耦合的结构，但添加了一个通用的通信系统，通常通过 RESTful API。该系统通过减少服务之间的数据转换，允许单独的组件更快地进行通信。微服务架构几乎总是与 REST API 结合使用。

  它们越来越受欢迎，因为每个服务都可以迭代和改进，而不会影响其他服务的风险。每一个都足够隔离以适应并被抽象，以便对一项服务的更改不会破坏其他服务。