rpc 跟 restful 之间有什么关系 ？

• 資深大佬 : ChanKc

  前后端分离和 restful rpc 都没有关系

• 資深大佬 : hantsy

  Java EE 标准中原来有一个 XML RPC，从 Jakarta EE 9 正式标注为 Pruned，删除。
  基于 SOAP WebService 的相关标准，标注为 Optional，不是强制要求 Provider 实现。
  剩下的只有 JAXRS，基于 REST 的 WebService 了。

• 資深大佬 : roundRobin

  RPC 指的是利用暴露的函数接口通讯的模式,REST 是利用标准接口访问资源的设计模式,前者对内提供微服务,后者对外提供用户服务,前后端分离是项目的设计模式,要具体到内部通讯和外部访问才能和 RPC 或者 REST 扯上关系

• 資深大佬 : kenzi

  再加一点，getUserInfo 这种对于 rest 来说应该是 GET /user/{id}

• 資深大佬 : gabon

  HTTP 也是 rpc

• 資深大佬 : baiyi

  @gabon #5 “HTTP is not RPC” —— Fielding Dissertation

• 資深大佬 : zarte

  rpc 可以使用 http 协议那就跟 restful 差不多了，但是 rpc 可以自定义协议达到更小的包等优势。

• 資深大佬 : useben

  一句话, 一个是协议, 一个是设计模式

• 資深大佬 : iX8NEGGn

  后端服务之间远程调用目前两大主流分别是 rpc(远程过程调用) 和 RESTful 风格的 http，rpc 一般工作在应用层以下，而 http 是应用层协议，RESTful 只是 http 调用的一种风格和 rpc 没关系，你前后端交互 API 设计也可以用 RESTful 风格，前后端分离是一种软件设计模式和 RESTful 或 rpc 都没关系

• 資深大佬 : limuyan44

  java 和 javascript 什么关系他们就什么关系

• 資深大佬 : Variazioni

  @limuyan44 哈哈哈哈

• 資深大佬 : qq1340691923

  @limuyan44 没关系

• 主 資深大佬 : fangcan

  @roundRobin 请教下，前端系统能不能理解为一个只调用接口不开放接口的后端程序？
• 資深大佬 : nthhdy

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

  我印象最深刻的，是这里面 易哥 的回答

• 資深大佬 : hcx0

  RPC 是一种泛指，Http 只是一种协议，可以通过 http 协议来实现、比如 gRPC 。
  REST 只是 Http 的一种设计风格，跟 RPC 没有必然的联系。
  前后端分离跟 REST 和 RPC 更没有关系。
  另外，虽然拥趸很多，但是 RESTful 风格的接口在国内几乎没有见过。

• 資深大佬 : js8510

  RPC: Remote procedure call. restful : Web services that conform to the REST architectural style, called RESTful Web services. 所以 RPC 有很多实现，http,thrift, grpc 等等。restful 是一种 RPC 设计规范。 用 wiki 的话说， 叫 set of constraints to be used for creating Web services. 所以关系大概就是 OS 和 POSIX 的关系。

• 資深大佬 : sxy960806

  @kenzi 资源的命名一般用单数还是复数呢？比如我看 github 的 v3api，就是 projects，而 auth 这种不可数的名词没有复数，user 有复数但写成 users 有点奇怪。比较纠结。。。

• 資深大佬 : kenzi

  @sxy960806 上面我是随手写的，具体 project 里，我们一般用复数比较多

• 資深大佬 : libook

  技术圈有个鸭子定律，就是走起来像鸭子、叫起来像鸭子、长得像鸭子，那就可以称之为鸭子。

  RPC 全程是 Remote Procedure Call，中文可以翻译成远程过程调用，所以只要是一个程序里像调用自己的过程一样去调用另外一个程序里的过程（可能是同一台机器上的，也可能是不同机器上的），那么就可以被称之为 RPC 技术。

  REST 是一中 API 设计风格（不是标准，不是标准，不是标准），这种风格是 Roy Fielding 博士于 2000 年发布的论文里提出的，用于解决一些 API 设计问题的风格，感兴趣可以看一看论文原文，篇幅很短。

  REST 是基于 HTTP 来设计的，HTTP 是超文本传输协议，用于实现客户端（浏览器）与服务端之间的数据通信。

  假设你的 VUE 页面以 REST 风格通过 HTTP 这个协议来与服务端的 SpringMVC 程序进行通信，同时 VUE 页面中将这个通信过程封装成了本地的方法，能实现页面业务逻辑可以直接调用本地方法，最终实现与服务器的数据交换；那么就可以说：
  – 这个可以用于与服务器交换数据的方法是一种 RPC 技术。
  – 此 RPC 技术底层使用 REST 风格的 HTTP API 来实现。

• 主 資深大佬 : fangcan

  @libook 也就是我所在的项目的前后端分离其实就是 “普通的前端应用以 http 调用后端服务”，调用方式也不是 rpc ；后端服务提供的服务也不是 rest 风格 是这样么？

• 資深大佬 : libook

  @fangcan 你没有说实现细节，所以我也无法判断。

  RPC 、REST 、前后端分离，三者之间没有任何联系，不互相依赖，也可以共存。就好比是车辆、汽油发动机、出行三者的关系；车辆可以用汽油发动机，也可用柴油发动机甚至电动机；汽油发动机可以给汽车用，也可以给船和发电机用；出行可以选择乘车，也可以选择乘船和飞机甚至自行车。

  RPC 和 REST，一个是针对调用的方式，另一个是针对通信方式，分别看。

  RPC 的精髓是，业务逻辑不需要关心本地的这个方法是如何实现和服务器通信的，本质上是对调用过程的一种封装，这样业务逻辑只需要关心自己的业务逻辑，RPC 只需要关心如何实现远程调用，两者隔离。

  REST 只是一种 API 的设计风格，只要你服务端的 API 风格符合 REST 的特征，那就算是用了 REST 风格。

  所以你搞清楚了之后可以自己判断一下，你现在是否在用 RPC 以及 REST 。

  不过我觉得你目前的思路是本末倒置的。不应该是先做完了一个设计再回过头来看做法是不是符合某种技术的特征；而是应该先分析需求，然后为了更科学地实现需求，根据不同技术的特征来选择其中最合适的来实现。