如果你是一个初学者，甚至一想到API都有些害怕。那是一种什么样的黑暗魔法？以及为什么每个人都向API开发者支付数十万的费用。难道他们喝血，在月光下围着羊群献祭吗？
应用程序接口（API，Application Programming Interface）是基于编程语言构建的结构，使开发人员更容易地创建复杂的功能。它们抽象了复杂的代码，并提供一些简单的接口规则直接使用。
来看一个现实中的例子：想想您的房子、公寓或其他住宅的供电方式，如果您想在您的房子里用电，只要把电器的插头插入插座就可以，而不是直接把它连接到电线上——这样做非常低效，而且对于不是电工的人会是困难和危险的。
图片来自：Overloaded plug socket 提供者： The Clear Communication People于Flickr
云原生应用开发是提高开发速度的一个明确办法，依赖于通过 API 连接微服务应用架构。
什么是API？
API 是 Application Programming Interface的缩写，但没有人这样称呼它，就像没有人称USB 为 Universal Serial Bridge（通用串行桥）。API 的技术含义是，它是一套用于构建、通信和集成应用软件的定义和协议，因此称为 "接口"。
但撇开技术术语不谈，API 只是一种与应用程序互动的方式，其内部工作原理对外部用户是不可见的。API 允许外部用户（客户）从应用程序或服务器 "请求 "(request)一些东西，并获得相应的 "响应"(response)。
事实上，你已经使用了相当于现实世界中的 API 。例如，乘坐老式的出租车。要想坐上出租车，你需要：
- "Request" ：要求出租车来接你，并附上你的联系方式和位置信息
- "Response"：在对你的请求的 "回应 "中，你会得到出租车的详细信息，并且出租车会来接你。
- 你再次 "要求 "（ "Request" ）出租车司机把你带到一个特定的地点。
- 在 "回应 "（"Response"）中，出租车司机将你送到你想要的地方。
现在，你不需要知道如何操作汽车，就能从一个地方到另一个地方，出租车司机就像一个API 。你可能对汽车的操作一无所知，但你可以与 API 层，也就是司机，进行互动，并导航到你想要的结果。
另一种看待 API 的方式是，它是一个神奇的盒子，以一种非常具体的格式接受输入，并以一种非常具体的格式给出输出。在应用程序开发中，这种输入和输出（I/O）的 "标准化 "是很有用的，它使开发者很容易与他们不控制的系统进行交互。
API 的类型
如果你听说过 API 这个词，有可能它是用来指一种非常特殊的 API 类型，叫做Web API。然而，一般来说，根据 API 的用途，API 一词可能有其他含义。
根据用途，API 可以大致分为以下四类：
- Web APIs 用于在服务器和客户端之间通过互联网进行通信。Web API 顾名思义是一种非常特殊的 API 类型，用于在互联网上互动和操作信息或资源。
- Remote APIs 定义了在不同机器上运行的应用程序的交互标准。例如，将数据库连接到程序的 JDBC 连接 API 。
- 库和框架作为软件的接口，也是 API 的一种。
- 操作系统可以为应用程序指定 API ，以便与设备互动。例如，带有摄像头的安卓设备需要一个操作系统 API ，以使任何应用程序能够控制摄像头。
远程 API 和 Web API 的区别
远程 API 旨在通过通信网络进行互动。这里的"远程"是指 API 操控的资源不在提出请求的计算机上。由于互联网是应用最广泛的通信网络，所以大多数 API 都是基于 Web 标准来设计的。并非所有的远程 API 都是 Web API，但可以认为 Web API 都是远程 API。
Web API 通常会使用 HTTP 来传输请求消息，并提供响应消息的结构定义。这些响应消息通常都会以 XML 或 JSON 文件的形式来提供。XML 和 JSON 都是首选格式，因为它们会以易于其他应用操纵的方式来呈现数据。
什么是 Web API？
Web API用于服务器和客户端之间通过互联网或任何网络进行通信。通常，Web API使用HTTP（超文本传输协议，HyperText Transfer Protocol）请求方法，也被称为 HTTP 动词，与服务器进行通信。
HTTP标准（RFCs 7231和RFC 5789，但这并不重要）规定了一套 "请求方法"，表明要执行的行动。
这些HTTP请求方法是:
- GET：从一个端点 "获取 "指定的资源。这导致了服务器的响应，而服务器的状态没有任何变化。
- POST：向一个终端发送一些数据，通常会产生一个动作，反过来改变服务器的状态。
- PUT : 替换服务器上的一些数据。与POST类似，但不同的是，PUT请求将始终产生相同的结果。
- DELETE : DELETE方法从服务器上删除指定的资源。
- HEAD : HEAD方法要求一个像GET请求那样的响应，但只有状态行和头部分。
- CONNECT : CONNECT方法建立一个隧道到目标资源识别的服务器。
- OPTIONS : OPTIONS方法用于描述目标资源的通信选项。
- TRACE : TRACE方法沿着通往目标资源的路径进行消息回环测试。
- PATCH : PATCH方法用于对一个资源进行部分修改。
API 设计简化
在 API 逐步发展成为当前随处可见的 Web API 的过程中，人们对它进行了一些改进，简化了设计并改进了它的实施成效。
REST 与 SOAP 的区别
随着 Web API 的不断普及，相应的协议规范也随之产生了，从而推动了信息交换的标准化：简单对象访问协议，简称 SOAP。使用 SOAP 设计的 API 会使用 XML 格式来收发消息，并通过 HTTP 或 SMTP 来接收请求。使用 SOAP 时，在不同环境中运行的应用或使用不同语言编写的应用能够更加轻松地共享信息。
相关的规范还有一个，即：表述性状态传递（REST）。遵循 REST 架构约束的 Web API 被称为 RESTful API。REST 与 SOAP 有着根本区别：SOAP 是一种协议，而 REST 是一种架构模式。这意味着 RESTful Web API 没有官方标准。正如 Roy Fielding 在论文 "Architectural Styles and the Design of Network-based Software Architectures"（架构模式以及基于网络的软件架构的设计）中定义的那样，只要 API 符合 RESTful 系统的 6 个导向性约束，就算作 RESTful API：
- 客户端/服务器架构：REST 架构由客户端、服务器和资源构成，通过 HTTP 来处理请求。
- 无状态：请求所经过的服务器上不会存储任何客户端内容。与会话状态相关的信息会存储在客户端上。
- 可缓存性：通过缓存，可免去客户端与服务器之间的某些交互。
- 分层系统：客户机与服务器之间的交互可以通过额外的层来进行调解。这些层可以提供额外的功能，如负载均衡、共享缓存或安全防护。
- 按需代码（可选）：服务器可通过传输可执行代码来扩展客户端的功能。
- 统一接口：这项约束是 RESTful API 的设计核心，共涵盖 4 个层面：
- 识别请求中的资源：请求中的资源会被识别，并与返回给客户端的表示内容分离开来。
- 通过不同的表示内容来操纵资源：客户端会收到表示不同资源的文件。这些表示内容必须提供足够的信息，以便执行修改或删除操作。
- 自描述消息：返回给客户端的每个消息都包含充足的信息，用于指明客户端应该如何处理所收到的信息。
- 将超媒体作为应用状态的引擎：在访问某个资源后，REST 客户端应该能够通过超链接来发现当前可用的所有其他操作。
虽然看似有很多约束需要遵循，但是这些约束遵循起来要比遵循规定的协议容易得多。因此，RESTful API 现在变得比 SOAP 更为普及。
近年来， OpenAPI 规范已成为定义 REST API 的通用标准。OpenAPI 为开发人员提供了一种与语言无关的方式来构建 REST API 接口，从而最大程度减少不确定的因素，让用户安心工作。
面向服务的架构（SOA）和微服务架构
最常使用远程 API 的 2 种架构方案分别是： 面向服务的架构（SOA）和微服务架构 （点击了解微服务的优势）架构。在这 2 种方案中，SOA 的历史更为久远一些。最初，它是在单体式应用的基础上经过改进而形成的。虽然单个单体式应用也可以完成各种操作，但通过某种集成模式（如企业服务总线（ESB））在不同应用间实现松散耦合后，即可获得某些功能。
从大多数层面来看，SOA 都要比单体式架构更简单；但是，如果无法明确理解各种组件交互，SOA 也可能会进一步加剧整个环境的复杂性。这种复杂性的加剧会重新引发 SOA 想要解决的某些问题。
对于专用松散耦合服务的使用，微服务架构与 SOA 模式类似。但是，微服务架构会对传统架构进行进一步细分。在微服务架构中，服务会采用通用消息传递框架，如 RESTful API。它们会使用 RESTful API 来实现相互通信，且无需执行繁琐的数据转换处理或使用其他的集成层。使用 RESTful API 可以加速新功能和新更新的交付；甚至还可以说，是这类 API 促进了这种速度的提升。该架构中的每一个服务都呈离散状态。一个服务可以被取代、增强或丢弃，而不会影响架构中的任何其他服务。这种轻量级架构有助于优化分布式资源或云资源，而且能够支持个别服务的动态扩展。
