Web Service和REST（中）

Posted 2021-08-08 weixin_43802541

6.2 RPC和REST

目录：

1. 6.2.1 RPC

2. 6.2.2 REST

REST近年来成为最主流的Web服务器设计模型，已经普遍取代了基于SOAP和WSDL的接口设计

6.2.1 RPC

6.2.1.1 RPC概念

RPC(Remote Procedure Call)：远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的思想。

RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有：

应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。

远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。

通信框架：MINA 和 Netty。目前流行的开源 RPC 框架还是比较多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的gRPC、Twitter 的 Finagle 等

简单解释：

RPC=SOAP+WSDL+UDDI

6.2.1.2 RPC框架

在一个典型 RPC 的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中“RPC协议”就指明了程序如何进行网络传输和序列化。

例如阿里Dubbo的设计框架图，分层清晰，功能复杂：

6.2.1.3 RPC 核心功能

RPC 的核心功能是指实现一个 RPC 最重要的功能模块，就是上图中的”RPC 协议”部分

一个 RPC 的核心功能主要有 5 个部分组成，分别是：客户端、客户端 Stub、网络传输模块、服务端Stub、服务端等

6.2.1.4 RPC 核心之功能实现

RPC 的核心功能主要由 5 个模块组成，如果想要自己实现一个 RPC，最简单的方式要实现三个技术点，分别是：

服务寻址

数据流的序列化和反序列化

网络传输

6.2.1.5 RPC 核心之网络传输协议

在 RPC 中可选的网络传输方式有多种，可以选择 TCP 协议、UDP 协议、HTTP 协议。

基于TCP协议和基于HTTP协议RPC调用方式对比:

1. 基于 TCP 的协议实现的 RPC 调用，由于 TCP 协议处于协议栈的下层，能够更加灵活地对协议字段进行定制，减少网络开销，提高性能，实现更大的吞吐量和并发数。

但是需要更多关注底层复杂的细节，实现的代价更高。同时对不同平台，如安卓，ios 等，需要重新开发出不同的工具包来进行请求发送和相应解析，工作量大，难以快速响应和满足用户需求。

2. 基于 HTTP 协议实现的 RPC 则可以使用 JSON 和 XML 格式的请求或响应数据。

而 JSON 和 XML 作为通用的格式标准(使用 HTTP 协议也需要序列化和反序列化，不过这不是该协议下关心的内容，成熟的 Web 程序已经做好了序列化内容)，开源的解析工具已经相当成熟，在其上进行二次开发会非常便捷和简单。

但是由于 HTTP 协议是上层协议，发送包含同等内容的信息，使用 HTTP 协议传输所占用的字节数会比使用 TCP 协议传输所占用的字节数更高。

3. 因此在同等网络下，通过 HTTP 协议传输相同内容，效率会比基于 TCP 协议的数据效率要低，信息传输所占用的时间也会更长，当然压缩数据，能够缩小这一差距

6.2.2 REST

6.2.2.1 什么是REST

REST – REpresentational State Transfer 直接翻译：表现层状态转移

RESTful – 如果一个架构符合REST风格就称它为RESTful架构

RESTful service是一种架构模式，近几年比较流行，它的轻量级web服务，发挥HTTP协议的原生的GET，PUT，POST，DELETE。

REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁，越来越多的web服务开始采用REST风格设计和实现。

例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST 并非始终是正确的选择。它作为一种设计 Web 服务的方法而变得流行，这种方法对专有中间件（例如某个应用程序服务器）的依赖比基于 SOAP 和 WSDL 的方法更少。在某种意义上，通过强调URI和HTTP等早期 Internet 标准，REST 是对大型应用程序服务器时代之前的Web 方式的回归。

先解释和REST概念有关的三个概念：资源、表现层、状态转化

资源：

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，就是一个具体的实在。可以用一个URI指向它，要获取这个资源，访问这个URI就可以

表现层：

REST的表现层状态转化省略了主语，表现层的其实指的就是资源的表现层

资源是信息实体，可以有多种表现形式，资源的具体表现形式就是表现层

例如文本可以用txt格式，也可以用html、json、xml等格式

URI只代表资源的实体，不代表他的形式

例如网址的最后的.html不是必要的，属于表现层范畴，URI应该只代表资源位置，它的的具体表现形式应该在HTTP的请求HEAD中Accept和Content-Type指定，这两个字段才是对表现层的描述

状态转化：

访问网站，代表了客户端和服务器端的互动，势必涉及数据和状态的变化

HTTP是一个无状态协议，所有的状态都保存在服务器端。如果客户端要操作服务器就需要通过方法，让服务器发生状态转化

而这种状态转化是建立在表现层之上的，所以是表现层状态转化

6.2.2.2 RESTful架构

RESTful架构的几个特点为：

1. 资源

2. 统一接口

3. URI

4. 无状态
   

统一接口：

RESTful 架构风格规定，数据的元操作，即 CRUD(Create，Read，Update 和 Delete，即数据的增删查改)操作，分别对应于 HTTP 方法：GET 用来获取资源，POST 用来新建资源(也可以用于更新资源)，PUT用来更新资源，DELETE 用来删除资源，这样就统一了数据操作的接口，仅通过 HTTP 方法，就可以完成对数据的所有增删查改工作。

URI：

可以用一个 URI(统一资源定位符)指向资源，即每个 URI 都对应一个特定的资源。

要获取这个资源，访问它的 URI 就可以，因此 URI 就成了每一个资源的地址或识别符。

无状态：

所谓无状态的，即所有的资源，都可以通过 URI 定位，而且这个定位与其他资源无关，也不会因为其他资源的变化而改变。有状态和无状态的区别。

举个简单的例子说明一下。

如查询员工的工资，如果查询工资是需要登录系统，进入查询工资的页面，执行相关操作后，获取工资的多少，则这种情况是有状态的。因为查询工资的每一步操作都依赖于前一步操作，只要前置操作不成功，后续操作就无法执行。

如果输入一个 URI 即可得到指定员工的工资，则这种情况是无状态的，因为获取工资不依赖于其他资源或状态。

且这种情况下，员工工资是一个资源，由一个 URI 与之对应，可以通过 HTTP 中的 GET 方法得到资源，这是典型的 RESTful 风格

总结：

什么是RESTful架构：

1. 每个URI代表一种资源

2. 客户端和服务器之间，传递这种资源的某种表现层

3. 客户端通过HTTP的四个方法GET、POST、PUT、DELETE，对服务器资源进行操作，实现表现层状态转化

6.2.2.3 RPC和RESTful架构对比

面对对象不同：

RPC 更侧重于动作。

REST 的主体是资源。

RESTful 是面向资源的设计架构，但在系统中有很多对象不能抽象成资源，比如登录，修改密码等而

RPC 可以通过动作去操作资源。所以在操作的全面性上 RPC 大于 RESTful。

传输效率：

RPC 效率更高。RPC，使用自定义的 TCP 协议，可以让请求报文体积更小，或者使用 HTTP2 协议，也可以很好的减少报文的体积，提高传输效率。

复杂度：

RPC 实现复杂，流程繁琐。

REST 调用及测试都很方便。

RPC 实现需要实现编码，序列化，网络传输等。而 RESTful 不要关注这些，RESTful 实现更简单。

灵活性：

HTTP 相对更规范，更标准，更通用，无论哪种语言都支持 HTTP 协议。

RPC 可以实现跨语言调用，但整体灵活性不如 RESTful。

【未完待续…】