【布道 API】浅谈 API 设计风格

API 风格是一个备受争议的话题，大多数开发者都熟悉 REST 与 GraphQL 的争论，更不用说其他风格了。本文将介绍常见的 8 种不同的 API 风格。

API 有哪些风格呢？

按照不同的特征可以分为五类，如下：

• Web API：REST 和 so-called REST
  

• 查询 API：GraphQL
  

• 发布订阅 API：包括 Kafka 和 WebSub
  

• RPC API ：SOAP 和 gRPC
  

• 普通的文件传输

约束、属性

具体使用哪种 API 风格，一般需要考虑约束、属性和关键因素，这里不考虑架构的影响因素。

考虑以下约束和属性之间关系的示例：

• 解耦（约束）的 API 本质上是可修改的（属性）

• 无状态（约束）的 API 本质上是可靠的（属性）和可扩展的（属性）

• 实现统一接口（约束）的 API 本质上是简单的（属性）

当然，约束也会导致负面属性，例如，效率低下是一种可能由统一接口的约束引起的。但是，要选择正确的 API 风格，需要考虑对项目团队因素（效率、质量、成本）。

要选择想要的属性，需要考虑团队的局限性。

• 业务限制：例如用例、客户要求、发布时间

• 地域限制：例如地域政策限制

• 技能限制：例如团队文化、团队技能

• 复杂性限制：包括风格难度、可扩展性需求和算法复杂性

除了上面的考虑因素，你可能发现要构建具有特定属性的 API，还有一些常见的考虑因素，如可移植性、可见性和安全性。是的，下面的因素也是需要考虑的：

• 性能

• 可扩展性

• 易用性

• 可修改性

• 可靠性

• 可发现性

• 易于开发

• 成本

和前面的因素相比，下面的因素不那么关键但又不得不考虑：

• 成熟度

• 企业适用性

• 工具

• 社区

• 特定风格的资源

• 易于开放

选择正确 API 风格的建议：综合考虑以上的因素就会知道选择哪种风格，但要做到这一点，还需要知道常见的八种 API 风格在约束、特征。

REST

REST（REpresentational State Transfer），首次出现在 2000 年 Roy Thomas Fielding 的博士论文中，提出了一种万维网的软件架构风格-REST（全称：Representational State Transfer， 表现层状态转换），目的是便于在不同软件/程序中（例如互联网）中互相传递信息。它指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 REST 的。

约束：客户端-服务器、无状态、可缓存、分层系统、按需代码、统一接口

特征：性能、简单性、可扩展性、可见性、可移植性、可发现性、可修改性、可靠性

REST 非常适合构建持久的可扩展系统。它也是一种相对灵活和成熟的风格，因此适用于内容协商、多媒体和顶级身份验证等内容。

So-called REST

called 和 so-called 都表示所谓，区别在于，前者是名词性从句，后者是一个形容词，因此在 REST 的设计上主要在于端点的设计。

约束：客户端-服务器、无状态、可缓存、分层系统、按需代码、统一接口

特征：性能、简单性、可扩展性、可见性、可移植性、可发现性、可靠性

So-called REST 是大多数团队的首选，因为遵循 HTTP 协议并提供 REST 的所有属性，统一接口。不幸的是，没有这种约束意味着 So-called REST 提供的可修改性很差。

GraphQL

GraphQL 是一个开源的，面向 API 而创造出来的数据查询操作语言以及相应的运行环境。 于 2012 年仍处于 Facebook 内部开发阶段，直到 2015 年才公开发布。 2018 年 11 月 7 日，Facebook 将 GraphQL 项目转移到新成立的 GraphQL 基金会。

约束：客户端-服务器、无状态、分层系统、统一接口

特征：易于开发、成本、类型安全

GraphQL 提供了令人难以置信的工具和出色的开发体验，可以快速设置和使用，并且可以很好地用于后端和前端的通信。它的发展不如 REST。

Apache Kafka

Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由 Scala 和 Java 编写。该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。其持久化层本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，这使它作为企业级基础设施来处理流式数据非常有价值。

约束：客户端-服务器，无状态，统一接口

特征：性能、可见性、可扩展性、可发现性、可靠性、类型安全

Kafka 是一种流行的发布订阅风格，快速、可靠且可扩展。虽然它具有基于消息的系统的所有优点：永久存储消息，但它并不适合作为开放平台发布，并且需要大量的 Java 功能。

WebSub

WebSub 是一种在互联网传播分布式发布/订阅的开放标准。这种协议为数据订阅延伸了 Atom 和 RSS 协议。主要是为了提供即时更新通知，这将改善客户端获得任意间隔 feed 之情况。

约束：客户端-服务器、无状态、可缓存、分层系统、按需代码、统一接口

特征：简单性、可扩展性、可见性、可移植性、可发现性、可修改性、可靠性

WebSub 是另一种发布订阅 API 风格，从 REST 继承，即使在对外开放也能很好地工作，与语言无关。但是，性能肯定不如 Kafka。

SOAP

SOAP 是交换数据的一种协议规范，使用在计算机网络 Web 服务中，交换带结构的信息。SOAP 为了简化网页服务器从 XML 数据库中提取数据时，节省去格式化页面时间，以及不同应用程序之间按照 HTTP 通信协议，遵从 XML 格式执行资料互换，使其抽象于语言实现、平台和硬件。

约束：客户端-服务器，分层系统

特征：可见性、可发现性

它可能不是最现代的风格，但是 SOAP 仍然有它的用途。它非常适合在现有的企业基础设施上进行构建，特别是对于一对一的集成。然而，对于长期战略，一定要考虑其他风格。

gRPC

gRPC 是 Google 发起的一个开源远程过程调用 系统。该系统基于 HTTP/2 协议传输，使用 Protocol Buffers 作为接口描述语言。 其他功能： 认证 双向流 流控制 超时 最常见的应用场景是： 微服务框架下，多种语言服务之间的高效交互。

约束：客户端-服务器

特征：性能、简单性、可靠性、安全

gRPC 是一个由谷歌支持的基本 RPC 框架，虽然拥有出色的性能，但它保证了对 REST 或 GraphQL 已经提供的大部分内容进行改造。它不适用于 web 应用程序，也不适用于消息代理。

File Transfer

文件传输是指计算机文件通过信道从一台计算机传输到另一台计算机。在计算机历史上，针对不同的文件传输情况，人们设计了许多文件传输协议。

约束：客户端-服务器

特性：易于开发，成本低

简单的文件传输很容易被忽视，不过这是一种廉价且简单的数据传输方式。非常适合不需要频繁的批处理，也不需要实时功能的场景。

总结

上面简单介绍了常见的 8 种 API 风格的约束和特征，有一个大概的了解，后续将会展开详细介绍。