API 架构风格演化史：CORBA-XMLRPC(SOAP)-REST-JSONRPC-GraphQL-gRPC

我们先来看一张 Twitter Architecture 2022

Code First v.s API First 软件开发理念的改变

下图显示了代码优先开发和API优先开发之间的差异。

为什么我们要考虑API优先设计?

• 微服务增加了系统的复杂性。
  我们有单独的服务来服务系统的不同功能。尽管这种体系结构促进了职责的脱钩和分离,但我们需要处理服务之间的各种通信。 
  最好在编写代码并仔细定义服务边界之前，仔细考虑系统的复杂性。
• 独立的职能团队需要说相同的语言。
  专门的功能团队仅负责自己的组件和服务。建议组织通过API设计使用相同的语言。 
  在编写代码之前,我们可以模拟请求和响应以验证API设计。
• 提高软件质量和开发人员生产力
  由于我们在项目开始时消除了大多数不确定性,因此整体开发过程更加顺畅,并且软件质量得到了极大提高。
  开发人员也对该过程感到满意,因为他们可以专注于功能开发,而不是协商突然的变化。
  在项目生命周期即将结束时有惊喜的可能性降低了。

因为我们首先设计了API,所以可以在开发代码时设计测试。在某种程度上,使用API首次开发时,我们还有TDD (测试驱动设计)。

• Microservices increase system complexity.
  We have separate services to serve different functions of the system. While this kind of architecture facilitates decoupling and segregation of duty, we need to handle the various communications among services. 
  It is better to think through the system's complexity before writing the code and carefully defining the boundaries of the services.
• Separate functional teams need to speak the same language.
  The dedicated functional teams are only responsible for their own components and services. It is recommended that the organization speak the same language via API design. 
  We can mock requests and responses to validate the API design before writing code.
• Improve software quality and developer productivity
  Since we have ironed out most of the uncertainties when the project starts, the overall development process is smoother, and the software quality is greatly improved.
  Developers are happy about the process as well because they can focus on functional development instead of negotiating sudden changes.
  The possibility of having surprises toward the end of the project lifecycle is reduced.

Because we have designed the API first, the tests can be designed while the code is being developed. In a way, we also have TDD (Test Driven Design) when using API first development.

API优先开发是一种软件开发方法，它在开发用户界面（UI）之前，优先开发应用程序编程接口（API）。此方法用于确保API的设计满足应用程序及其用户的需求。API First development is a software development approach that prioritizes the development of an application programming interface (API) before the development of the user interface (UI). This approach is used to ensure that the API is designed to meet the needs of the application and its users.

API architectural styles

由于RPC已成为热门话题,因此让我们简要回顾一下其历史。

API体系结构风格是一组用于创建和使用应用程序编程接口（API）的指南和最佳实践。它基于展示状态转移（REST）的原则，为设计、构建和使用API提供了一个框架。这种风格最早由Roy Fielding于2000年提出，此后成为设计web API的事实标准。

API architectural style is a set of guidelines and best practices for creating and using Application Programming Interfaces (APIs). It is based on the principles of Representational State Transfer (REST) and provides a framework for designing, building, and consuming APIs. The style was first proposed by Roy Fielding in 2000 and has since become the de facto standard for designing web APIs.

下图说明了API架构风格的发展历程。

随着时间的流逝,发布了不同的API样式。它们每个人都有自己的标准化数据交换模式。

API体系结构样式:REST API和GraphQL之间的差异

多年来,开发人员和分析师对于所谓的最佳API体系结构持有不同的意见。好吧,我们不是在这里支持或向任何各方表达我们的声音。我们将简单地向您展示两个非常流行和经常使用的API框架之间的区别：REST和GraphQL。

在调查中, REST和GraphQL是使用最多的5种体系结构之一。REST在该特定调查中名列前茅,超过80%的受访者选择它作为他们选择的API体系结构。但是请记住,每种样式都有其优点和局限性。选择一个时,请考虑您的用例,用户的期望,而不仅仅是对此的普遍争论更好。

REST 架构风格

REST(展示状态转移)是一种架构方法,用于设计和启用Web上计算机系统之间的标准,从而使系统可以更轻松地相互连接和通信。基于REST框架样式制作的API通常被描述为RESTful系统。它们以无国籍状态和系统独立性而著称。

为了更好地理解,API是允许两台或多台计算机或Web系统通信和交换资源的连接器或通道系统。也就是说,一个系统通过API获得对另一个系统的访问权,以获取对其资源的访问权。现在,REST是设计API的框架。还有其他建筑风格。

可恢复的系统通常由两方组成;服务器和客户端,它们适应HTTP模型和协议

REST支持几乎所有编码语言,并允许各种数据表示。但是,主要限制是RESTful API必须符合 REST设计协议, 称为体系结构约束

REST支持几乎所有编码语言,并允许各种数据表示。但是,主要限制是RESTful API必须符合REST设计模式,即体系结构约束:

统一接口

这意味着类似信息的每个API执行都应统一。应该始终有一种与特定服务器连接的标准方法。每个资源都应具有自己独特的URI (统一资源标识符),客户端可以通过询问服务器来访问它。

无状态（Stateless）

使用REST框架,客户端必须提供执行查询所需的所有信息。不允许服务器程序保留与客户端请求相关的任何数据,因此,尽管每个请求的频率很高,但它们都被视为新请求。

客户端-服务器独立性

这意味着尽管系统的通信需求和连接,客户端和服务器应用程序也必须独立运行。客户端应仅知道所寻求信息的URI;它无法以任何其他方式与服务器系统通信。同样,服务器系统应仅提供所请求的信息,而不应提供其他任何信息。它不应存储数据或以任何其他方式与客户端进行交互。

可缓存的

REST API要求缓存应适当地应用于资源。目的是增强客户端的操作并促进服务器上更好的适应性。

分层系统

REST允许您采用分层系统设计,这意味着服务器和客户端之间的API通信可以经过几层。但是,它的设计使客户端无法识别它是直接链接到目标服务器还是通过中介。

按需代码

REST API通常提供静态资源,但是在某些情况下,响应还可能包括可执行代码。在这些情况下,仅在需要时执行代码。但是,此要求是可选的。

REST的优点

• 客户端和服务器独立性:REST框架内的系统可以独立运行并且仍然可以有效通信,这一事实使其成为合适的体系结构
• 方便和适应性:REST支持许多数据存储类型和编码语言。
• 缓存友好。REST是唯一允许数据缓存的框架。任何其他样式的缓存功能都需要配置单独的缓存子系统。

REST的缺点

• 获取过多和获取不足的问题:REST API有时会出现获取过多或获取不足的响应的问题,这通常会导致重新启动通信。
• 缺乏状态:大多数在线应用程序都需要使用状态技术。但是,由于REST具有无状态功能,因此客户端承担着维护状态的任务,从而使系统重量级且更难管理。
• 有限安全性:REST不像SOAP那样强制安全性。这就是为什么它可能不是客户端和服务器之间敏感数据传输的最佳选择。

GraphQL架构风格

Facebook在2015年创建了GraphQL,作为对REST框架的改进。它试图解决REST的缺点和效率低下的问题。例如,GraphQL允许客户端定义将从服务器收集的特定数据., REST无法做到这一点。GraphQL既是数据响应语言,又是执行引擎。

GraphQL与充当客户端发送和接收HTTP请求的结构的API进行交互。就像名称一样,GraphQL使用其高级查询语言以图形模式构造数据,以用于获取,提取和更改数据。

使用GraphQL,用户可以通过一个请求从多个资源获取数据。与发送多个请求的替代方法相比,这使API通信更加轻松和方便。

重要的是要注意,GraphQL不一定可以替代REST。您不必在两者之间进行选择。两者都可以简单地用于同一项目。

GraphQL的优点

• 复杂系统的好选择:使用GraphQL API,可以互连许多复杂的平台。GraphQL服务器还用于从已经起作用的系统访问信息,并以GraphQL输出格式显示它。
• 没有过度获取或获取不足的问题:这是GraphQL已纠正的重要问题之一。尽管REST通常包含太多或太少的数据,但GraphQL通过检索所需的精确数据而更有效。
• 灵活的权限:GraphQL允许您选择要公开的数据,同时保持敏感信息的专有性。另一方面,REST设计不会大量泄露数据。它要么检索所有内容,要么什么也没有检索。
• 速度:GraphQL明显比其他API结构快,因为它允许您仅通过选择要访问的区域来缩小请求范围。

GraphQL的缺点

• 性能问题:单个请求中的分层条目过多可能会导致系统故障或损坏。对于复杂的要求,REST可能是首选。
• GraphQL中的速率限制:GraphQL的另一个问题是它是速率限制的。在REST API中,您可以简单地指示一天内应执行的需求数量,但是在GraphQL中,很难做出这样的特定指示。
• 缓存困难:复杂缓存。由于GraphQL不会重用HTTP缓存规则,因此它需要一种专门的,大多数时候是复杂的缓存方法。

REST VS GraphQL

诚然,REST和GraphQL体系结构具有某些相似之处,因为它们是解决同一问题的两种不同方式。但是它们在可操作性和性能上有所不同。

让我们简要讨论两个框架之间的差异。

可操作性

REST和GraphQL API的运行方式完全不同,尤其是在版本化和传输查询结果时。

众所周知,GraphQL具有更好的可预测性。使用GraphQL,您可以将调用传输到API,并且仅接收所需的结果—。另一方面,REST倾向于发送比请求的数据更多的数据或比所需的数据更少的数据。

在版本控制方面,REST缺乏明确且明确的原则。这意味着允许每个提供商选择自己的版本控制方法。GraphQL根本不支持版本控制。

可用功能

REST更像是一种行业标准,已经存在了很多年。寿命长久的好处之一是它具有许多使其真正方便的功能。REST缺少GraphQL的某些功能包括:无状态服务器,缓存,分层系统,负载平衡器,标准接口等。

下表将突出显示其他差异。

结论

确定采用哪种API体系结构样式是酌情决定的,因为没有人能比其他人更好。最后,在选择要部署的样式之前,您可能必须考虑您的需求和项目的要求。