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的都清楚,页面发送请求就只有两种:POSTGET,也就是对应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)。最后非常感谢其他博主的博客!!

  • 5
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值