RestFul 与 RPC 的区别是什么
RestFul 与 RPC 的区别是什么?RestFul 的优点在哪里?
这个问题的话,确实被问过,但是不是很频繁。
主动展示自己熟悉 http 规范可能比较容易引出来,不然一般就是结合 RPC 问了。
不会很加分,还是防备式的一种问题
--
区别
● 设计目的上
○ RPC 是为了在分布式系统上不同机器的函数调用隐藏细节就像本地函数调用一样
○ RESTful API,一种架构规范,设计目的就是为了规范管理网络通信(把网络通信定义成对资源的操作 )
● 定义上
○ 个人暂时理解 restful 就是在正常使用 http 协议基础上的一个规范, rest 这个词表现层状态转换,表现层的定义就是客户端服务端的中间层。目前理解也没什么特殊含义,最终其实都是围绕「一个 http 请求一定是对资源的某种操作」这个核心设计来的;
○ rpc,远程过程调用。http 可以作为一种实现,你也可以在 tcp 上去自定义对字节流做相关的编解码处理。现有框架如 grpc 都选择了 http (http2) 作为应用层实现是为了保证兼容性,毕竟你要客户端同时实现编解码规则还是非常麻烦的。
● 主要特征
○ rest 无状态(其实我感觉,虽然 mdn 说 http 是无状态但是可以通过 cookie 保持一种会话,还不如说 rest 是无状态的),rpc 可以方便的在调用间改变状态。rest 无状态是说每个请求是独立的可以任意 顺序执行,就算你是 post 单次执行也都是独立的。rpc 可能每次调用就是相关联的一组函数了,甚至你几次执行还要加上分布式事务。
○ rest 主要基于 http 方法,这样简单的规则对资源进行操作。rpc 则一般更灵活,可以实现更复杂的操作。虽然说 http 理论上也可以 handler 执行任何过程,但是那不是 rest 的设计目的,反而是应该避免的,这些都算是副作用。
● 使用场景
○ rpc 更快性能更高,一般用长连接做维持,也不用 json 做编解码。能满足高性能、实时性、强类型要求的场景。
○ rpc 常用于服务间相互调用,也是因为内部方便规范;rest 适用于前端客户端往服务端请求,或者对外服务。
优点
● 首先个人感觉上,restful 在接口特别多的时候优势比较明显。
○ 他是一种规范一种整理,比较常见的反例就是接口 url 直接使用行为代替,比如 POST /updateTweet? Id={id}对比 PUT /tweets/{id}。
○ 实践中,如果有大量接口,那么遵守 rest 规范天生就是一种整理。资源目录就是一种分类,@ 才能表示行动,路径参数直接能定位到某个对象的所有资源,同样的路径不同的 HTTP 方法表示不同的意义... 这些都是一种让人很畅快的「整理手段」。
● restful 更容易被缓存。
● 服务端负担更轻。
--
参考
● https://aws.amazon.com/cn/compare/the-difference-between-rpc-and-rest
● https://aws.amazon.com/cn/what-is/restful-api
● http 无状态的定义是两次请求执行成功互不影响 https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview#basic_aspects_of_http
不过感觉里边很多点目前还是理解不了,上面的整理还是非常有限。所以还是有问题请指出来
--
今天更水了,实习的事情被卡死了,真想跑了
#每天一篇简单博客 day3 (个人打卡,欢迎监督
这个问题的话,确实被问过,但是不是很频繁。
主动展示自己熟悉 http 规范可能比较容易引出来,不然一般就是结合 RPC 问了。
不会很加分,还是防备式的一种问题
--
区别
● 设计目的上
○ RPC 是为了在分布式系统上不同机器的函数调用隐藏细节就像本地函数调用一样
○ RESTful API,一种架构规范,设计目的就是为了规范管理网络通信(把网络通信定义成对资源的操作 )
● 定义上
○ 个人暂时理解 restful 就是在正常使用 http 协议基础上的一个规范, rest 这个词表现层状态转换,表现层的定义就是客户端服务端的中间层。目前理解也没什么特殊含义,最终其实都是围绕「一个 http 请求一定是对资源的某种操作」这个核心设计来的;
○ rpc,远程过程调用。http 可以作为一种实现,你也可以在 tcp 上去自定义对字节流做相关的编解码处理。现有框架如 grpc 都选择了 http (http2) 作为应用层实现是为了保证兼容性,毕竟你要客户端同时实现编解码规则还是非常麻烦的。
● 主要特征
○ rest 无状态(其实我感觉,虽然 mdn 说 http 是无状态但是可以通过 cookie 保持一种会话,还不如说 rest 是无状态的),rpc 可以方便的在调用间改变状态。rest 无状态是说每个请求是独立的可以任意 顺序执行,就算你是 post 单次执行也都是独立的。rpc 可能每次调用就是相关联的一组函数了,甚至你几次执行还要加上分布式事务。
○ rest 主要基于 http 方法,这样简单的规则对资源进行操作。rpc 则一般更灵活,可以实现更复杂的操作。虽然说 http 理论上也可以 handler 执行任何过程,但是那不是 rest 的设计目的,反而是应该避免的,这些都算是副作用。
● 使用场景
○ rpc 更快性能更高,一般用长连接做维持,也不用 json 做编解码。能满足高性能、实时性、强类型要求的场景。
○ rpc 常用于服务间相互调用,也是因为内部方便规范;rest 适用于前端客户端往服务端请求,或者对外服务。
优点
● 首先个人感觉上,restful 在接口特别多的时候优势比较明显。
○ 他是一种规范一种整理,比较常见的反例就是接口 url 直接使用行为代替,比如 POST /updateTweet? Id={id}对比 PUT /tweets/{id}。
○ 实践中,如果有大量接口,那么遵守 rest 规范天生就是一种整理。资源目录就是一种分类,@ 才能表示行动,路径参数直接能定位到某个对象的所有资源,同样的路径不同的 HTTP 方法表示不同的意义... 这些都是一种让人很畅快的「整理手段」。
● restful 更容易被缓存。
● 服务端负担更轻。
--
参考
● https://aws.amazon.com/cn/compare/the-difference-between-rpc-and-rest
● https://aws.amazon.com/cn/what-is/restful-api
● http 无状态的定义是两次请求执行成功互不影响 https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview#basic_aspects_of_http
不过感觉里边很多点目前还是理解不了,上面的整理还是非常有限。所以还是有问题请指出来
--
今天更水了,实习的事情被卡死了,真想跑了
#每天一篇简单博客 day3 (个人打卡,欢迎监督
全部评论
相关推荐
11-04 13:32
门头沟学院 游戏后端 点赞 评论 收藏
分享