主流的 API 架构
- 1. RPC:调用另一个系统的函数
- 2. SOAP:使数据作为服务可用
- 3. REST:使数据作为资源可用
- 4. GraphQL:仅请求所需要的数据
1. RPC:调用另一个系统的函数
远程过程调用是一种允许在不同上下文中远程执行函数的规范。RPC 扩展了本地过程调用的概念,并将其放在 HTTP API 的上下文中。
最初的 XML-RPC 是存在问题的,因为很难确保 XML 有效负载的数据类型。因此,后来 RPC API 开始使用一个更具体的 JSON-RPC 规范,该规范被认为是 SOAP 的更简单的替代方案。gRPC 是 Google 在 2015 年开发的最新 RPC 版本。gRPC 可插拔支持负载均衡、追踪、运行状况检查和身份验证,它非常适合连接不同的微服务
RPC 的工作机制
客户端调用一个远程的过程,将参数和附加信息序列化为消息,然后将消息发送到服务端。服务端在接受到消息后,将信息的内容反序列化,执行所请求的操作,然后将结果发送回客户端。客户端和服务端各自负责参数的序列化和反序列化。
RPC 的优势
简单直接的交互。 RPC 使用 GET 来获取信息,使用 POST 来处理其他所有操作。服务端和客户端之间交互的机制归结为调用端点并获得响应。
易于添加新函数。 如果 API 有了新的需求,我们可以轻松地添加另一个执行这个需求的端点:1)编写一个新函数,并将其放在一个新端点之后;2)现在,客户可以访问这个端点,并获取符合其需求的信息。
高性能 。轻量级的有效负载不会对网络产生压力,以此提供高性能,这对于共享服务器和在工作站网络上执行并行计算非常重要。RPC 还能够优化网络层,使得不同服务之间每天发送海量消息变得非常高效。
RPC 的不足
和底层系统紧密耦合。 API 的抽象级别有助于其可重用性。API 与基础系统的耦合越紧密,对其他系统的可重用性就越差。RPC 与基础系统的紧密耦合不允许其在系统函数和外部 API 之间建立抽象层。这很容易引起安全问题,因为关于基础系统的细节实现很容易会泄漏到 API 中。
RPC 的紧密耦合使得可伸缩性要求和松散耦合的团队难以实现。因此,客户端要么会担心调用特定端点的带来的任何可能的副作用,要么需要尝试弄清楚要调用的端点,因为客户端不了解服务器如何命名其函数。
可发现性低。 在 RPC 中,无法对 API 进行检验总结,或者发送请求来开始理解根据需求应该调用哪个函数。
函数爆炸性增长 。创建新函数非常容易。因此,相较于重新编辑现有的函数,我们会倾向于创建新的功能,最终产生大量难以理解的、功能重叠的函数。
2. SOAP:使数据作为服务可用
SOAP 是一个 XML 格式的、高度标准化的网络通讯协议。在 XML-RPC 发布的一年后,SOAP 由微软发布、并继承了许多 XML-RPC 的特性。在 REST 紧随其后发布,一开始它们是被同时使用,但很快 REST 赢得了这次比赛,成为了更流行的协议。
SOAP 的工作机制
XML 数据格式拖累了很多数据规范。伴随着大量的消息结构,XML 数据格式使得 SOAP 成为了最冗长的 API 架构风格。
SOAP 的工作机制
XML 数据格式拖累了很多数据规范。伴随着大量的消息结构,XML 数据格式使得 SOAP 成为了最冗长的 API 架构风格。
SOAP 的消息由这些部件组成:
- 一个信封标签:用于开始和结束每条消息
- 包含请求或响应的正文
- 一个标头:用于表示消息是否由某些规范或额外要求的来确认
- 故障通知:包含了可能在请求处理过程只能够发生的任何错误
SOAP API 的逻辑由 Web 服务描述语言(WSDL)编写。该 API 描述语言定义了端点并描述了可以执行的所有过程。这使得不同的编程语言和 IDE 能够快速建立通信。
SOAP 支持有状态和无状态消息传递。在有状态的情况下,服务器存储接收到的信息可能非常繁琐复杂。但这对于涉及多方和复杂交易的操作是合理的。
SOAP 的优势
独立于语言和平台 。内置创建 Web 服务的功能使得 SOAP 能够处理消息通信的同时发送独立于语言和平台响应。
绑定到各种协议 。SOAP 在适用于多种场景的传输协议方面是十分灵活的。
内置错误处理 。SOAP API 规范允许返回带有错误码及其说明的的 XML 重试消息
SOAP 的不足
如今,由于如下几种原因,许多开发人员在听到必须集成 SOAP API 的想法后都会感到不安。
仅使用 XML 。SOAP 消息包含大量的元数据,并且在请求和响应时仅支持繁冗的 XML 格式。
重量级 。由于 XML 文件的大小,SOAP 服务需要很大的带宽。
非常专业化的知识 。构建 SOAP API 服务器需要对所有涉及到的协议以及它们及其严格的限制都有很深的了解。
乏味的消息更新 。由于需要额外的工作来添加或者删除某个消息属性,这种死板的 SOAP 模式减慢了其被采用的速度。
3. REST:使数据作为资源可用
REST 如今是一种无需解释的 API 架构风格,它由一系列的架构约束所定义,旨在被广泛 API 使用者采用。
当前最常见的 API 架构风格最初时由 Roy Fielding 在其博士论文中提出的。REST 使得服务端的数据可用,并以简单的格式(通常是 JSON 和 XML)来表示它。
REST 的优势
客户端和服务端的解耦 :由于 REST 尽可能地解耦了客户端和服务端,REST 相较于 RPC 可以提供更好的抽象性。具有抽象级别的系统能够封装其实现细节,以更好的标示和维持它的属性。这使得 REST API 足够灵活,可以随着时间的推移而发展,同时保持稳定的系统。
可发现性 :客户端和服务端之间的通信描述了所有内容,因此不需要外部文档即可了解如何与 REST API 进行交互。
缓存友好 :REST 重用了许多 HTTP 工具,也是唯一一种可以在 HTTP 层面上缓存数据的 API 架构风格。与其相对的是,在任何其他 API 上实现缓存都需要配置其他缓存模块。
多种格式支持 :REST 拥有支持多种格式用于存储和交换数据的能力,这是它如今成为搭建公共 API 的主要选择的原因之一。
REST 的不足
没有标准的 REST 结构 :在构建 REST API 方面,没有具体的正确方法。如何对资源进行建模以及哪些资源需要建模取决于不同的情况。这使得 REST 在理论上很简单,但在实践中却很困难。
庞大的负载: REST 会返回大量丰富的元数据,以便客户端可以仅从响应中了解有关应用程序状态的所有必要信息。对于具有大量带宽容量的大型网络系统来说,这种“啰嗦”的通信并不算很大的负载。但带宽容量并非总是足够的。这也是 Facebook 在 2012 年提出 GraphQL 架构风格的关键驱动因素。
响应过度和响应不足问题 。REST 的响应包含的数据会过多或不足,通常会导致客户端需要发送另一个请求。
4. GraphQL:仅请求所需要的数据
GraphQL 是一种语法,它描述了如何进行精确的数据请求。有些应用程序的数据模型具有许多相互引用的复杂实体,在这种情况下,实现 GraphQL 是值得的。
GraphQL 的工作机制
GraphQL 从构建模式(Schema)开始。模式是对于用户可以在 GraphQL API 中进行的所有查询及其返回的所有类型的描述。模式构建非常困难,因为它需要使用模式定义语言(SDL)进行强类型化。
因为在客户端进行查询之前已经定义好了模式,所以客户端可以验证其查询语句,以确保服务端能够对查询语句进行响应。在查询语句到达后端应用程序时,GraphQL 操作将根据整个模式进行解释,并向前端应用程序返回解析到的数据。API 向服务端发送一个庞大的查询,该 API 返回一个仅包含我们所需数据的 JSON 响应。
GraphQL 的优势
具有类型的模式 :GraphQL 提前公开了它能做什么,从而提高了其可发现性。通过将客户端指向 GraphQL API,我们可以发现什么查询语句是可用的。
主流的 API 架构的更多相关文章
- 4 种主流的 API 架构风格对比
1RPC:调用另一个系统的函数 RPC 的工作机制 客户端调用一个远程的过程,将参数和附加信息序列化为消息,然后将消息发送到服务端.服务端在接受到消息后,将信息的内容反序列化,执行所请求的操作,然后将 ...
- 移动端API架构 统一Proxy还是各自为政?
今天首先回答上一篇的问题: 为什么APP通过运营商接入网络,连通率会那么差? 1. 域名缓存问题 运营商的localdns会缓存域名的解析结果,不向权威DNS递归查询解析 为什么要这么干呢? 1)运营 ...
- RESTful API 架构解读
RESTful API 架构解读 首先我们还是先介绍下 RESTful api 的来龙去脉. 首先, RESTful (下文都简称 RESTful api 为 RESTful ) 1.RESTful ...
- 爱奇艺直播 - 春晚直播业务API架构
小结: 1.服务熔断策略 在网关服务中经常会对后端不同api接口做服务聚合,比如A服务 -> B服务 -> C服务 ,如果C服务出现问题,那么在调用C服务之前需要做熔断.而在设计熔断器的时 ...
- Java生鲜电商平台-统一格式返回的API架构设计与实战
Java生鲜电商平台-统一格式返回的API架构设计与实战 说明:随着互联网各岗位精细化分工的普及,出现了很多的系统架构设计,比如常见的前后端分离架构,后端提供接口给前端,前端根据接口的数据进行渲染,大 ...
- 深入理解 RESTful Api 架构
转自https://mengkang.net/620.html 一些常见的误解 不要以为 RESTful Api 就是设计得像便于 SEO 的伪静态,例如一个 Api 的 URL 类似于 http: ...
- RESTful api架构设计
阮老师的这两篇文章足够了 理解 RESTful 架构 RESTful API 设计指南
- RESTful API架构和oauth2.0认证机制(概念版)
1. 什么是REST REST全称是Representational State Transfer,中文意思是表述(编者注:通常译为表征)性状态转移. 它首次出现在2000年Roy Fielding的 ...
- openresty开发系列1--网关API架构及选型
微服务架构在项目中的应用越来越多,我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些 ...
随机推荐
- 从 ClickHouse 到 ByteHouse:实时数据分析场景下的优化实践
本文来自火山引擎公众号,原文发布于2021-09-06. 近日,字节跳动旗下的企业级技术服务平台火山引擎正式对外发布「ByteHouse」,作为 ClickHouse 企业版,解决开源技术上手难 &a ...
- 使用systemd将iptables规则在docker启动后自动导入
编写systemd文件 $ sudo vi /etc/systemd/system/iptables-import.service # /etc/systemd/system/iptables-imp ...
- centos服务器上挂载exFat U盘
有些场景,我们需要在服务器上插入U盘,但是现在的U盘或者移动硬盘,大多都是exFat格式的,有时候linux系统识别不了,可以按照以下方式挂载. 1.安装nux repo(可以不装) yum inst ...
- Maven打包及场景
场景一 对当前项目打包并指定主类. <build> <plugins> <plugin> <artifactId>maven-compiler-plug ...
- vim一键整理代码命令
vim下写代码超实用代码格式整理命令,仅需四步 ①先使用 gg 命令使光标回到第一行 ②shift+v 进入可视模式 ③shift+g 全选 ④按下 = 即可 混乱的代码格式 四步整理以后 工整又 ...
- Rest使用get还是post
1. get是从服务器上获取数据,post是向服务器传送数据. 2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中,值和表单内各个字段一一对应,在URL中可以看到.post是通过 ...
- redis 之 集群
#:下载源码包,并编译安装 [root@localhost src]# wget http://download.redis.io/releases/redis-4.0.14.tar.gz [root ...
- virtualBox 系统移植
把virtualbox已经存在的系统移植到其他机器. 1.把系统如下文件考到一个安装了virtualbox的机器. 2.点击控制-->注册 然后浏览到复制的文件路径. 3.修改uuid 不管是l ...
- NSURLSession下载文件-代理
- 3.1 涉及知识点(1)创建NSURLSession对象,设置代理(默认配置) ```objc //1.创建NSURLSession,并设置代理 /* 第一个参数:session对象的全局配置设置 ...
- 【Linux】【Services】【KVM】安装与简单配置
1. 环境: 1.1. OS: Red Hat Enterprise Linux Server release 7.4 (Maipo) 1.2. Kernel: 3.10.0-693.el7.x86_ ...