SpringMvc第三天

Java ing 小

已于 2024-09-13 16:09:54 修改

阅读量646

点赞数 11

文章标签： spring java intellij-idea

于 2024-09-13 16:09:43 首次发布

本文链接：https://blog.csdn.net/gannimeiwent/article/details/142213544

版权

SpringMvc第三天

REST简介

什么是REST?

REST实质

什么是RESTful？

REST风格优缺点
REST入门案例
RESTful快速开发
小结

一，REST简介

1.什么是REST？

缩写：REST （不是"rest"这个单词）
外文名：Representational State Transfer，简称REST。
中文名：表现层状态转移。

提出时间：2000年。
属性：一种软件架构风格。（以Web为平台的。web服务的架构风格，前后端接口时候用到。）

REST之所以晦涩难懂，是因为前面主语（Resource ）被去掉了。
全称是： Resource Representational State Transfer。
通俗来讲就是：资源在网络中以某种表现形式进行状态转移。

分解开来讲解:
Resource：资源，即数据（这是网络的核心）

[比如你现在正在阅读一篇名为《REST 设计风格》的文章，这篇文章的内容本身（你可以将其理解为其蕴含的信息、数据）我们称之为“资源”。无论你是购买的书籍、是在浏览器看的网页、是打印出来看的文稿、是在电脑屏幕上阅读抑或是手机上浏览，尽管呈现的样子各不相同，但其中的信息是不变的，你所阅读的仍是同一份“资源”。]
Representational：表征，比如用JSON，XML，JPEG等

[当你通过电脑浏览器阅读此文章时，浏览器向服务端发出请求“我需要这个资源的 HTML 格式”，服务端向浏览器返回的这个 HTML 就被称之为“表征”，你可能通过其他方式拿到本文的 PDF、Markdown、RSS 等其他形式的版本，它们也同样是一个资源的多种表征。可见“表征”这个概念是指信息与用户交互时的表示形式，这与我们软件分层架构中常说的“表示层”（Presentation Layer）的语义其实是一致的。]

State：状态，在特定语境中才能产生的上下文信息

[当你读完了这篇文章，想看后面是什么内容时，你向服务器发出请求“给我下一篇文章”。但是“下一篇”是个相对概念，必须依赖“当前你正在阅读的文章是哪一篇”才能正确回应，这类在特定语境中才能产生的上下文信息即被称为“状态”。我们所说的有状态（Stateful）抑或是无状态（Stateless），都是只相对于服务端来说的，服务器要完成“取下一篇”的请求，要么自己记住用户的状态：这个用户现在阅读的是哪一篇文章，这称为有状态；要么客户端来记住状态，在请求的时候明确告诉服务器：我正在阅读某某文章，现在要读它的下一篇，这称为无状态。]

Transfer：转移,通过HTTP的动词（get查询、post新增、put修改、delete删除）实现

[无论状态是由服务端还是客户端来提供的，“取下一篇文章”这个行为逻辑必然只能由服务端来提供，因为只有服务端拥有该资源及其表征形式。服务器通过某种方式，把“用户当前阅读的文章”转变成“下一篇文章”，这就被称为“表征状态转移”。]

2.REST实质：

URL中只使用名词来定位资源，用HTTP协议里的动词（GET、POST、PUT、DELETE）来实现资源的增删改查操作。

什么意思呢？
比如，我们有一个friends接口，对于“朋友”我们有增删改查四种操作，怎么定义REST接口？

增加一个朋友，uri: generalcode.cn/v1/friends 接口类型：POST
删除一个朋友，uri: generalcode.cn/va/friends 接口类型：DELETE（在http的parameter指定好友id）
修改一个朋友，uri: generalcode.cn/va/friends 接口类型：PUT（在http的parameter指定好友id）
查找一个朋友，uri: generalcode.cn/va/friends 接口类型：GET

上面我们定义的四个接口就是符合REST协议的，请注意，这几个接口都没有动词，只有名词friends，都是通过Http请求的接口类型来判断是什么业务操作。

举个反例：
generalcode.cn/va/deleteFriends 该接口用来表示删除朋友，这就是不符合REST协议的接口。
不能用deleteFriends ，而应该就用friends + http请求的delete方式。
一般接口的返回值绝大部分是JSON类型的。

REST本质上是一种分布式超媒体系统的应用层解决方案，它为资源互通和资源管理的分离提出了一系列架构约束和原则，得到一个功能强、性能好、适宜通信的以网络为基础的应用软件架构。

3.什么是RESTFUL？

从上面的定义中，我们可以发现REST其实是一种组织Web服务的架构，
并不是实现Web服务的一种技术（注意：不是一种技术！！！也不是一种标准！！！），
其目标是为了创建具有良好扩展性的分布式系统。

反过来，作为一种架构，其提出了一系列架构级约束。这些约束有：

1.使用客户/服务器(b/s、 c/s)模型。客户和服务器之间通过一个统一的接口来互相通讯。
2.层次化的系统。在一个REST系统中，客户端并不会固定地与一个服务器打交道。
3.无状态。在一个REST系统中，服务端并不会保存有关客户的任何状态。也就是说，客户端自身负责用户状态的维持，并在每次发送请求时都需要提供足够的信息。
4.可缓存。REST系统需要能够恰当地缓存请求，以尽量减少服务端和客户端之间的信息传输，以提高性能。
5.统一的接口。一个REST系统需要使用一个统一的接口来完成子系统之间以及服务与用户之间的交互。这使得REST系统中的各个子系统可以独自完成演化。

如果一个系统满足了上面所列出的五条约束，那么该系统就被称为是RESTful的。

4.REST风格优缺点

4.1优点

隐藏资源的访问行为，无法通过地址得知对资源是何种操作。

不仅仅可以表示saveUser的保存操作，还可以是deleteUser的删除操作等等。但是，这里就有疑惑了，这是怎么让电脑知道你要执行什么样的操作的？

统一接口，统一URL，书写简洁。

4.2缺点

REST 与 HTTP 完全绑定，不适合应用于要求高性能传输的场景中

**带宽和延迟：**HTTP协议本身包含较多的开销，比如请求头、响应头等，这些在高频率、低延迟需求的场景下可能会成为瓶颈。

连接建立：每次HTTP请求都需要建立TCP连接（虽然有HTTP Keep-Alive机制减少连接建立的开销），对于需要频繁交互的场景，这会增加额外的延迟。

无状态性：虽然无状态性使得服务端更易于扩展，但每次请求都需携带所有上下文信息，可能增加数据传输量。

**协议选择：**对于那些对实时性、吞吐量、低延迟有严格要求的应用，如在线游戏、金融交易、实时音视频通信等，REST+HTTP的组合可能不是最佳选择。这些场景可能更适合采用更轻量级的协议或二进制协议（如WebSocket、protobuf配合gRPC、MQTT等），它们能够提供更低的延迟、更高的数据压缩效率和更优的二进制编码性能。

REST 不利于事务支持

如果“事务”指的是数据库那种的狭义的刚性 ACID 事务，那除非完全不持有状态，否则分布式系统本身与此就是有矛盾的（CAP 不可兼得），这是分布式的问题而不是 REST 的问题。如果“事务”是指通过服务协议或架构，在分布式服务中，获得对多个数据同时提交的统一协调能力（2PC/3PC），譬如WS-AtomicTransaction、WS-Coordination这样的功能性协议，这 REST 确实不支持，假如你已经理解了这样做的代价，仍决定要这样做的话，Web Service 是比较好的选择。如果“事务”只是指希望保障数据的最终一致性，说明你已经放弃刚性事务了，这才是分布式系统中的正常交互方式，使用 REST 肯定不会有什么阻碍，谈不上“不利于”。

REST 没有传输可靠性支持
REST（Representational State Transfer）本身作为一种架构风格，并不直接涉及传输层的可靠性保证。REST关注的是如何设计分布式系统中的组件，以便它们可以以一种统一且可预测的方式相互通信，特别是通过HTTP等应用层协议。关于传输的可靠性，实际上是底层传输协议的责任，而非REST架构直接提供的功能。
为什么这么说？

层次分离：REST架构遵循网络分层原则，其中传输可靠性通常由传输层（如TCP/IP模型中的TCP协议）处理。TCP协议提供了数据包的确认、重传和排序等机制，确保数据的可靠传输，而HTTP协议构建于TCP之上，享受这些可靠性保障。
无状态性：REST的一个核心原则是无状态性，服务器不保存关于客户端的上下文信息，每个请求都是独立的。这要求每个请求都携带完成操作所需的所有信息，但并不直接涉及传输可靠性。
HTTP的错误处理：虽然HTTP协议（REST常用协议）提供了一些机制来处理请求失败的情况，如通过状态码（如4xx和5xx系列）来表示客户端或服务器错误，但这更多是关于请求处理的结果反馈，而非传输过程的可靠性保证。
可选的可靠性增强机制：对于需要更高可靠性的RESTful服务，开发者可以采用应用层的解决方案，如幂等性设计、事务补偿逻辑、重试策略、消息队列等，来增强最终的业务操作可靠性，但这已经超出了REST架构本身的范畴。
因此，说REST没有传输可靠性支持，是因为它作为一个架构风格，专注于资源表述和操作，而传输可靠性是由其下层的网络协议（如TCP）以及上层的应用设计策略共同提供的。

REST 缺乏对资源进行“部分”和“批量”的处理能力
REST 开创了面向资源的服务风格，却肯定仍并不完美。以 HTTP 协议为基础给 REST 带来了极大的便捷（不需要额外协议，不需要重复解决一堆基础网络问题，等等），但也是 HTTP 本身成了束缚 REST 的无形牢笼。譬如你仅仅想获得某个用户的姓名，RPC 风格中可以设计一个“getUsernameById”的服务，返回一个字符串，尽管这种服务的通用性实在称不上“设计”二字，但确实可以工作；而 REST 风格中你将向服务端请求整个用户对象，然后丢弃掉返回的结果中该用户除用户名外的其他属性，这便是一种“过度获取”（Overfetching）。

二，REST入门案例

1.入门案例步骤

1.1创建一个web的Maven项目

1.2pom.xml添加依赖

servlet依赖+sprinmvc依赖+Json-datebind依赖+构建配置tomcat7插件的参数端口号，项目路径，url编码

1.3编写SpringMVC配置类，加载处理请求的Bean

1.4加载SpringMVC配置，并设置SpringMVC请求拦截的路径

1.5定义处理请求的功能类（RestAController）

1.5.1 查询所有。这个直接定义使用get方式。

1.5.2新增一条数据。访问方法使用post。

1.5.3修改一条数据。访问方法使用put

1.5.4 删除一条数据。既需要传参数，有需要改变访问的方式。访问路径：“/resta/{id}”；访问方式：delete；传值：直接在路径后面

2.发现问题

问题1：每个方法的@RequestMapping注解中都定义了访问路径/books，重复性太高。

问题2：每个方法的@RequestMapping注解中都要使用method属性定义请求方式，重复性太高。

问题3：每个方法响应json都需要加上@ResponseBody注解，重复性太高。

三，REST快速开发

1.@RequestMapping注解

名称：@RequestMapping

**类型：**方法(或类)注解

**位置：**SpringMVC控制器方法定义上方

**作用：**设置当前控制器方法请求访问路径

解决问题1：在Controller类上使用@RequestMapping定义共同的访问路径。

2.@RestController注解

名称：@RestController

**类型：**类注解

**位置：**基于SpringMVC的RESTful开发控制器类定义上方

**作用：**设置当前控制器类为RESTful风格，等同于@Controller与@ResponseBody两个注解组合功能

解决问题2：在Controller类上使用@RestController注解，等同于@Controller与@ResponseBody两个注解组合功能

3.增删改查

名称：@GetMapping @PostMapping @PutMapping @DeleteMapping

**类型：**方法注解

**位置：**基于SpringMVC的RESTful开发控制器方法定义上方

**作用：**设置当前控制器方法请求访问路径与请求动作，每种对应一个请求动作

@GetMapping对应GET请求，查询数据
@PostMapping对应POST请求，添加数据
@PutMapping 对应PUT请求，修改数据
@DeleteMapping对应DELETE请求，删除数据

解决问题3：使用@GetMapping @PostMapping @PutMapping @DeleteMapping代替@RequestMapping(method=RequestMethod.XXX)

四，总结

1.什么是REST

REST是设计风格而不是标准。REST通常基于使用HTTP，URI，和XML以及HTML这些现有的广泛流行的协议和标准。

1.资源是由URI来指定。
2.对资源的操作包括获取、创建、修改和删除资源，这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
3.通过操作资源的表现形式来操作资源。
4.资源的表现形式则是XML或者HTML，取决于读者是机器还是人，是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。

2.REST能干什么

因为REST设计风格基于HTTP协议，所以整个设计将通过四个动词状态（GET / PUT / DELETE / POST）对请求进行功能类别定义。通过这种定义形式，我们可以将一个对于URL的处理方法对应为4种类型的处理模式，大大降低了开发的复杂程度；另外，通过对HTTP状态码的处理我们可以讲后台的一部分不重要的业务逻辑转移到前台进行处理，这将简化服务器与客户端之间信息传输的大小（HTTP状态码为固定存在）