Rest风格（概念+实现）

转载请标明原创：https://blog.csdn.net/weixin_41896463/article/details/101083114

写在前面：

这是我之前为了学习REST风格，查了几篇大佬的博客再结合自己理解写下来的笔记，之前很少写博客都是写笔记，现在准备整理笔记后多多写博。

因为时间挺久，所以忘记了是查阅了哪些大佬们的博客，如果读者们知道是哪些博主的博客，麻烦告诉我，我会添加查阅链接，肥肠感谢！

参考博客链接：

REST什么是

即 Representational State Transfer（资源状态转化）。这是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便。

互联网上所有的信息都可以看成是一种资源，我们访问互联网本质上都是在对资源进行操作。每个资源都对应一个特定的URI，我们通常通过此URI进行对资源的访问。

资源有着不同的表现形式，比如文本有txt、html、json等格式，对资源的操作实际上就是对资源进行形式的转化。

通常对资源的操作是什么？就是最基本的CURD（增删改查）。

传统的接口

传统方式的接口有下面几种缺点：

互联网现在使用最多的协议是http协议，然而人们只是把HTTP当做一个传输的通道，没有把HTTP当做一种传输协议

怎么理解？一个很简单的例子，在过去（或者说现在也是）人们使用http协议的请求方式的时候，post和get占大多数（其他请求方式很少使用）而且对http的自身的返回值格式也是很少使用到，一般都是前后端亲自花时间定义和协商所传输的json格式，才可以进行相应的解析。

很明显这把http功能弱化，自己还去花时间搞不统一不规范的小圈子适用的风格和规则。有现成的不用，是不是sha？

URI命名规则混乱，不够清楚

为什么这么说呢？打个比方，如果我们要删除书库中id为1的图书信息，传统的URI设计结果为 /deletebook?id=1，单个来看好像也没有什么不妥，还挺简洁明了的。

但是如果项目成长起来，不单单是对图书操作，还有顾客、供应商等等，每一个model的每一个操作都需要一个URI，而且一万个人心里有一万个Url的命名规则，没统一的规则一乱起来就是一堆乱码啊。

还有，传统的接口URI设计，同样违背了URI的设计本意。

本人觉得这是比较重要的一点。URI是什么？统一资源定位符，重点是什么？是资源。也就是每一个URI是对应资源的唯一标识符。也就是说，URI不应该包含对资源的操作形式，不应该出现动词，它的作用只是一个代词作用而已，代指这某种资源！所以类似delete、add等这种动词实际上不应该出现在URI中。

正是因为传统URI设计的缺点，才诞生了REST风格的URI。可以使用非常简洁的URL地址来发送请求，同时还能很好地利用http本身的一些特性（http请求方式、http状态码等）

REST风格的URI格式

使用http的请求方式对应对数据的操作
- GET 获取资源（get）
- POST 新建资源（add）
- PUT 更新资源（update）
- DELETE 删除资源（delete）

传统的 查询1号图书  /getBook?id=1 删除1号图书  /deleteBook?id=1 更新1号图书  /updateBook?id=1&bookName=…… 添加图书     /addBook?bookName=…… REST风格(命名规则： /资源名/资源标识符) 查询1号图书 GET        /book/{id} 删除1号图书 DELETE     /book/{id} 更新1号图书 PUT        /book/{id,bookName,…} 添加图书 POST          /book/{id,bookName,…}

返回值中使用http的状态码，而不必协商新的状态码

REST风格的特点

REST是面向资源的，资源是通过 URI 进行暴露，而URI不会包含对资源的操作
REST是统一接口的，通过http不同的请求方式对资源进行相应的操作
REST初衷是无状态的，即所有资源都可以通过URI来定位，和其他的资源无关

对无状态的解释

现在互联网上很多都是有状态的。什么是有无状态？

举个很简单的例子：现在大部分网站的部分资源都是需要用户登录才可以获取得到的，比如只有登录了B站账号才可以查看个人信息，这就是有状态的：有无登录的状态会影响我能否查看得到个人信息。

对于REST设计初衷来说，它是希望URL是无状态的，每个资源的请求都不依赖于其他资源或其他请求，只要知道其URL，就都是可以访问的。显然无状态更加方便客户端使用服务器资源。（然而现实上很少实现无状态）

此外在REST基础上的HATEOAS（这个就不详细说了，可以参考其他博主的博客），返回的json里增加了相应的关系和url，给使用者带来了很大的便利，使用者只需要知道如何获取资源的入口，之后的每个URI都可以通过请求获得，无法获得就说明无法执行那个请求。

现在绝大多数的REST都只做到将HTTP作为了一种传输协议，上面这种更高层次的较少。而且上面这种有部分人认为多此一举，在单纯的数据中增加了一堆可能用不到的垃圾信息，违背的REST简洁为主的风格。

REST怎么使用（代码层面，SSM）

学习过javaweb的都清楚，页面发送请求就只有两种：POST 和 GET，也就是对应Rest风格中的添加和查询资源两种操作。

（超链接访问是GET请求，表单提交的方式可以设置POST、GET方式）

那么其他两个操作怎么实现？也就是如何从页面发送PUT和DELETE形式的请求呢？

很简单，Spring提供了对REST风格的支持：SpringMVC中有filter（过滤器，依赖于serlvet），可以把普通的请求转化为规定形式的请求。一般有下面几步：

在web.xml中配置这个filter

<filter> <filter-name>hiddenHttpMethodFilter</filter-name> <filter-class>org.springframework.web.filter.HiddenHttpMethodFilter</filter-class> </filter>
<filter-mapping> <filter-name>hiddenHttpMethodFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

前端页面创建一个post类型的表单，表单项中增加一个name为_method，value为delete/put的隐藏参数，以删除为例

<form action="book/1" method="post"><input type="hidden" name="_method" value="delete"><input type="submit" value="删除图书"/>
</form>

在controller中确定相应的处理，以删除为例

/*注意@RequestMapping一定要增加method属性，否则会因为url重复而报错*（因为/book/{bid}还可能有查询，区分只是请求方式）
**//*加上@ResponseBody注解，否则回应为tomcat版本问题导致页面显示405错误： *JSPs only permit GET POST or HEAD
**//* 删除图书 */
@ResponseBody
@RequestMapping(value = "/book/{bid}", method = RequestMethod.DELETE)
public String deleteBook(@PathVariable("bid")int id){ System.out.println("删除了 " + id + " 号图书"); return "success";
}

以上就是有关REST风格的简单介绍，并不算很深入，想要更加深入地学习我就帮不了啦（我也不懂hhh）。最后非常感谢其他博主的博客！！