码迷,mamicode.com
首页 > 其他好文 > 详细

Restful风格到底是什么?怎么应用到我们的项目中?

时间:2018-07-03 14:50:59      阅读:337      评论:0      收藏:0      [点我收藏+]

标签:details   方法   视图   解决   soa   架构模式   ade   use   pos   

rest越来越流行,感觉挺高大尚的。网上看了很多网友的说法,各有各的看法,我觉得很多说得很有道理。
说法一
restful风格,就是一种面向资源服务的API设计方式,它不是规范,不是标准,它一种设计模式。以前流行的web service服务都是面向过程,基于RPC协议的SOAP协议,对于现在或者未来,更多的人了解并且深受SOA思想影响,以面向服务为目标,而现在的SOAP虽然支持SOA,但存在很很大的差别,所以,慢慢就流行基于restful风格的web service。说简单一点,就是它纯粹面向资源,面向服务的思想,目前J2EE6的JAX-RS就是这种restful风格实现的新技术。
说法二
作者:张立理
链接:http://www.zhihu.com/question/33959971/answer/57593571
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

阮一峰的那篇文章我认为没有讲到实质,他能让人大概知道Restful是啥,但无法令人信服地知道REST是一种和以往不同的、在一定场景下有一定优势的架构方式

REST的全称在文章里已经有了,其中的核心是第一个字母R,即资源(Resource)

REST的核心在于,当你设计一个系统的时候,资源是第一位的考虑,你首先从资源的角度进行系统的拆分、设计,而不是像以往一样以操作为角度来进行设计

我们平时搞系统是这样的:

1.有新建用户功能
2.新建用户需要一个URL
3.往这个URL发送的数据要定义好
4.开始写后端和前端

这是以操作为第一位的设计方法,首先我们确认了一个操作,然后围绕这个操作把周边需要的东西建设好,这种方式当然可以架构出一个系统,甚至是一个好系统,但是偶尔会有些问题:

1.操作之间是会有关联,你的设计容易变成“第2个操作要求第1个操作进行过”,这种关系多起来你的系统就乱了
2.你的URL设计会缺乏一致性
3.操作通常被认为是有副作用(Side Effect)的,所以很少有人基于操作去设计缓存之类的东西

基于这些问题,我们的另一种方法是基于资源的角度来搞,但这个太难了我至今其实没想明白到底是怎么搞的,但基于资源会有一些好处:

1.各个资源虽然可能有关联,但依旧是能够简单地切掉这些关联导致相互独立的,所以不会有非常乱的耦合性
2.对资源的操作就这么几种,所以很容易设计一致的URL
3.我们明白对资源的读操作是无副作用的,所以能玩缓存

但其实现在99%说自己是REST的情况,就是改了个URL风格,用了用PUT和POST,根本没有明白REST是一个什么,也没有按REST的思想来指导设计,在我看来纯粹就是在作秀

要说自己会REST,我觉得至少回答2个问题:

1.对于用户登录和用户退出这两个业务需求,REST指导下的架构和设计如何满足
2.批量的删除、修改、新增如何满足

说法三
作者:Tony
链接:http://www.zhihu.com/question/33959971/answer/58671683
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

应题主要求,简要回答它的优势或优点。
首先,REST规范:

1.强调HTTP应当以资源为中心,并且规范了资源URI的风格;
2.规范了HTTP请求动作(PUT,POST等)的使用,具有对应的语义;

遵循REST规范的Web应用将会获得下面好处:

1.URL具有很强可读性的,具有自描述性;
2.资源描述与视图的松耦合;
3.可提供OpenAPI,便于第三方系统集成,提高互操作性;
4.如果提供无状态的服务接口,可提高应用的水平扩展性;

下面再详细说明一下REST。了解事物,分三步走:

【基本概念】
REST是一种软件架构模式。核心概念包括:

资源(Resource):在REST中,资源可以简单的理解为URI,表示一个网络实体。比如,/users/1/name,对应id=1的用户的属性name。
既然资源是URI,就会具有以下特征:名词,代表一个资源;它对应唯一的一个资源,是资源的地址。

表现(Representation):是资源呈现出来的形式,比如上述URI返回的HTML或JSON,包括HTTP Header等;

【实践】
怎么用呢?不同的Server端框架提供了各种解决方案。比如JavaEE中的开箱即用的Spring-MVC。
但实践过程中,你自然会碰到一些需要思考的问题:
1)如何定义资源:一般对应数据库实体(在传统的关系型数据库中)。
2)需要对HTTP协议更多的理解
URL格式:协议://域名/路径?查询#HASH,实际的一个HTTP请求,还会包括Header(含Cookie、Method等)

资源的URI格式:协议://域名/路径,它只是URL的子集,表征一个资源实体。比如,http://a.com/users/1

恰当地理解和返回Http Status(状态码)。200=成功,404=资源不存在,500=服务器端错误等等。

3)REST操作
一般资源操作只有新增、删除、查询、更新,对应HTTP协议中四类请求:POST、DELETE、GET、PUT。其中,后三个操作是幂等的。(什么是幂等?)

查询资源时,更多的参数,比如分页、排序、过滤条件,一般都会放在URL的查询部分(Query String)。
新增、更新资源,关于资源实体的内容,一般放在请求体(Request Body)中。

实际发送请求,还需要有动词,表示对该资源执行什么样的操作。那么超出这个范围的操作该如何扩展?

REST操作返回什么内容?对于删除、新增、更新等操作,通常是返回操作是否成功的标识;如果失败,需要返回错误代码和消息,方便客户端做进一步处理。如果是查询操作,通常包含实体或者实体列表。
在最佳实践中,应当还应该返回与此操作相关的其他操作。比如,查询得到实体的响应中,应包含该实体的删除、更新操作的地址。

请求和返回的Body,采用什么格式?常见的格式包括XML/JSON/HTML。

说法四
持续整理中… …

 

 

个人倾向于:说法三,跟我目前的项目中的设计方式比较吻合

                            ——caogen1991

文章转自:https://blog.csdn.net/programmer_sir/article/details/51592433

Restful风格到底是什么?怎么应用到我们的项目中?

标签:details   方法   视图   解决   soa   架构模式   ade   use   pos   

原文地址:https://www.cnblogs.com/caogen1991/p/9257654.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!