【RPC vs RESTful】RPC vs RESTful--什么是REST和RESTful

REST 和 RESTful  

什么是REST:

URL定位资源,用HTTP动词(GET,POST,DELETE,DETC)描述操作。

 

在设计web接口的时候,REST主要是用于定义接口名,接口名一般是用名词写(代表资源),“获取”或者“删除”或者“更新”这样的操作用HTTP请求类型(POST、GET等)来区分。

 

比如,我们有一个friends接口(资源)),对于“朋友”我们有增删改查四种操作,怎么定义REST接口?

增加一个朋友,uri: generalcode.cn/va/friends 请求类型:POST

删除一个朋友,uri: generalcode.cn/va/friends 请求类型:DELETE

修改一个朋友,uri: generalcode.cn/va/friends 请求类型:PUT

查找朋友,uri: generalcode.cn/va/friends         请求类型:GET

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

举个反例:generalcode.cn/va/deleteFriends 该接口用来表示删除朋友,这就是不符合REST协议的接口。

 

一般接口的返回值是JSON或者XML类型的。

用HTTP Status Code传递Server的状态信息。比如最常用的 200 表示成功,500 表示Server内部错误,403表示Bad Request等。(反例:传统web开发返回的状态码一律都是200,其实不可取。)

那这种风格的接口有什么好处呢?前后端分离。前端拿到数据只负责展示和渲染,不对数据做任何处理。后端处理数据并以JSON格式传输出去,定义这样一套统一的接口,在web,ios,android三端都可以用相同的接口,是不是很爽?!

//原文:https://blog.csdn.net/intelrain/article/details/80449371

 

 

摘自:https://www.cnblogs.com/jager/p/6519321.html

在微服务中,使用什么协议来构建服务体系,一直是个热门话题。 争论的焦点集中在两个候选技术: (binary) RPC or Restful。

  1. 以Apache Thrift为代表的二进制RPC,支持多种语言(但不是所有语言),四层通讯协议,性能高,节省带宽。相对Restful协议,使用Thrifpt RPC,在同等硬件条件下,带宽使用率仅为前者的20%,性能却提升一个数量级。但是这种协议最大的问题在于,无法穿透防火墙。

  2. 以Spring Cloud为代表所支持的Restful 协议,优势在于能够穿透防火墙,使用方便,语言无关,基本上可以使用各种开发语言实现的系统,都可以接受Restful 的请求。 但性能和带宽占用上有劣势。

所以,业内对微服务的实现,基本是确定一个组织边界,在该边界内,使用RPC; 边界外,使用Restful。这个边界,可以是业务、部门,甚至是全公司。

 

使用RPC远程服务调用方式与传统http接口直接调用方式的差别在于:

1. 从使用方面看,Http接口只关注服务提供方,对于客户端怎么调用,调用方式怎样并不关心,通常情况下,我们使用Http方式进行调用时,只要将内容进行传输即可,这样客户端在使用时,需要更关注网络方面的传输,比较不适用与业务方面的开发;而RPC服务则需要客户端接口与服务端保持一致,服务端提供一个方法,客户端通过接口直接发起调用,业务开发人员仅需要关注业务方法的调用即可,不再关注网络传输的细节,在开发上更为高效。

2. 从性能角度看,使用Http时,Http本身提供了丰富的状态功能与扩展功能,但也正由于Http提供的功能过多,导致在网络传输时,需要携带的信息更多,从性能角度上讲,较为低效。而RPC服务网络传输上仅传输与业务内容相关的数据,传输数据更小,性能更高。

3. 从运维角度看,使用Http接口时,常常使用一个前端代理,来进行Http转发代理请求的操作,需要进行扩容时,则需要去修改代理服务器的配置,较为繁琐,也容易出错。而使用RPC方式的微服务,则只要增加一个服务节点即可,注册中心可自动感知到节点的变化,通知调用客户端进行负载的动态控制,更为智能,省去运维的操作。

 

http://blog.lixf.cn/essay/2017/02/17/microservice-7-rpc/

https://www.zhihu.com/question/28570307

 

 

 

扩展知识:

如何理解REST 这个名称(资源表述转移……)

2. 4 资源的链接

我们知道REST是使用标准的HTTP方法来操作资源的,但仅仅因此就理解成带CURD的Web数据库架构就太过于简单了。

这种反模式忽略了一个核心概念:"超媒体即应用状态引擎(hypermedia as the engine of application state)"。 超媒体是什么?

当你浏览Web网页时,从一个连接跳到一个页面,再从另一个连接跳到另外一个页面,就是利用了超媒体的概念:把一个个把资源链接起来.

要达到这个目的,就要求在表述格式里边加入链接来引导客户端。在《RESTful Web Services》一书中,作者把这种具有链接的特性成为连通性。下面我们具体来看一些例子。

下面展示的是github获取某个组织下的项目列表的请求,可以看到在响应头里边增加Link头告诉客户端怎么访问下一页和最后一页的记录。 而在响应体里边,用url来链接项目所有者和项目地址。

291731042784620

  又例如下面这个例子,创建订单后通过链接引导客户端如何去付款。

291731052313462

上面的例子展示了如何使用超媒体来增强资源的连通性。很多人在设计RESTful架构时,使用很多时间来寻找漂亮的URI,而忽略了超媒体。所以,应该多花一些时间来给资源的表述提供链接,而不是专注于"资源的CRUD"。

2. 5 状态的转移

有了上面的铺垫,再讨论REST里边的状态转移就会很容易理解了。

不过,我们先来讨论一下REST原则中的无状态通信原则。初看一下,好像自相矛盾了,既然无状态,何来状态转移一说?

其实,这里说的无状态通信原则,并不是说客户端应用不能有状态,而是指服务端不应该保存客户端状态。

2. 5.1 应用状态与资源状态

实际上,状态应该区分应用状态和资源状态,客户端负责维护应用状态,而服务端维护资源状态。

客户端与服务端的交互必须是无状态的,并在每一次请求中包含处理该请求所需的一切信息。

服务端不需要在请求间保留应用状态,只有在接受到实际请求的时候,服务端才会关注应用状态。

这种无状态通信原则,使得服务端和中介能够理解独立的请求和响应。

在多次请求中,同一客户端也不再需要依赖于同一服务器,方便实现高可扩展和高可用性的服务端。

但有时候我们会做出违反无状态通信原则的设计,例如利用Cookie跟踪某个服务端会话状态,常见的像J2EE里边的JSESSIONID。

这意味着,浏览器随各次请求发出去的Cookie是被用于构建会话状态的。

当然,如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息(比如认证令牌),这样的Cookie也是符合REST原则的。

2. 5.2 应用状态的转移

状态转移到这里已经很好理解了, "会话"状态不是作为资源状态保存在服务端的,而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。

这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。

3. 总结

现在广东XXX版本、XXX等项目中均使用传统的RPC、SOAP方式的Web服务,而移动南方基地XXXX项目的后台, 虽然采用了JSON格式进行交互,但还是属于RPC风格的。本文从资源的定义、获取、表述、关联、状态变迁等角度, 试图快速理解RESTful架构背后的概念。RESTful架构与传统的RPC、SOAP等方式在理念上有很大的不同,希望本文能对各位理解REST有所帮助。

 http://www.runoob.com/w3cnote/restful-architecture.html

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值