RPC和调用web服务有什么区别
What is the difference between RPC and calling web service
我刚读到 rpc http://www.grpc.io/ 远程过程调用，另一方面我们有 webservice 客户端向服务器发送请求，服务器响应。
rpc 也是如此，其中 stub 调用服务器端的方法。我认为同样的事情可以在 webservice.
的帮助下实现
rpc 有什么不同，用在什么地方更好？
RPC 是一种协议，一个程序可以使用该协议向位于网络上另一台计算机上的程序请求服务，而无需了解网络的详细信息。过程调用有时也称为函数调用或子例程调用。
"A dear child has many names"。 RPC、Soap WS、REST、RMI 和其他只是计算机之间通信的不同方式，它们有很多相似之处，无论您选择哪一种，都可以达到相同的最终结果。在这种情况下 (grpc)，RPC 只是一个通用的 "Remote Procedure Call" 名称，表明它的用途。
选择其中一项技术时，您需要了解其中的差异，例如，RMI 作为一项仅 Java 的技术，当您不在full-Java 环境（即使那样我也不会去尝试）。如果你真的喜欢 SOAP and/or XML，你可能想要使用常规的网络服务。如果您更喜欢 JSON 而不是 HTTP，那么 REST 可能是您的选择。如果您想追求前沿技术，您可能需要选择 grpc 或其他类似技术。
使用的技术通常由现有代码库决定，因此如果您以前使用过 SOAP 网络服务，您会继续使用它。
Web 服务促进松耦合。你应该更喜欢那个。 RPC 将您限制为某种编程语言。当您使用网络服务时，您可以使用不同的语言甚至不同的操作系统来交换信息。当您考虑连接多种设备时，您应该使用 web 服务，但是当您构建具有多个模块的分布式应用程序时，也许 RPC 更合适。
What rpc can make a difference and where it is better to use ?
rpc的优点
我看到的主要优点是您被迫在编译时捕获更多错误。
这个 gRPC-Web: Moving past REST+JSON towards type-safe Web APIs 上的 post 说：
- 无需再搜索 API 文档 – .proto 是规范的
API 合同的格式，就像在其他团队中一样
- 不再 hand-crafted JSON 调用 objects – 所有请求和响应都是强类型的并且 code-generated，有可用的提示
在 IDE
- 不再处理方法、headers、body 和低级网络——一切都在
grpc-web-client
- 不再有 second-guessing HTTP 错误代码的含义 – gRPC 状态代码是 API 中表示问题的规范方式
服务器上不再有 hand-crafted chunk-encoded 流媒体疯狂 – gRPC-Web 支持 1:1 RPC 和 1:many server-side
流媒体请求
- 推出新二进制文件时不再出现数据解析错误 – 向后 forwards-compatibility 请求和响应是
由协议缓冲区保证
面向协议架构的优势
我看到的主要优势是您拥有可以在不同场景中重复使用的标准操作和通用概念。
在Richardson Maturity Model - steps toward the glory of REST中引入了不同级别的概念。您可以从那里提取一些优势。
第 1 级通过使用分而治之的方法解决处理复杂性的问题，将大型服务端点分解为多个资源。
第 2 级介绍了一组标准的动词，以便我们以相同的方式处理类似的情况，消除不必要的变化。
级别 3 引入了可发现性，提供了一种使协议更 self-documenting。
的方法
什么时候使用什么？
也许 rpc 适合 in-house 当你有一个不熟悉 HTTP 或其他通用协议的领域专家团队时。它在不涉及浏览器的 backend-to-backend 通信 中也有优势。借助 gRPC 等技术，可以支持多个 languages/technologies.
之间的通信
在所有其他情况下 HTTP-like 通信似乎仍然是 2017 年大多数用例的标准？
即使很久以前就有人问过这个问题，我也想添加我的简短回答，但有一些关键差异，希望对未来的读者有所帮助。
------------------------------------------------------------------------------
| Category | RPC | Web Services
------------------------------------------------------------------------------
|Operation's Location | On top of TCP | on top of HTTP Protocol
------------------------------------------------------------------------------
|Data format | Binary | Text, XML, JSON, ect.
------------------------------------------------------------------------------
|Speed | Slow (Marshilling) | Fast
------------------------------------------------------------------------------
我没有提到RPC和Web Services的描述，因为你在别人的回答中看得很清楚。
我刚读到 rpc http://www.grpc.io/ 远程过程调用，另一方面我们有 webservice 客户端向服务器发送请求，服务器响应。
rpc 也是如此，其中 stub 调用服务器端的方法。我认为同样的事情可以在 webservice.
rpc 有什么不同，用在什么地方更好？
RPC 是一种协议，一个程序可以使用该协议向位于网络上另一台计算机上的程序请求服务，而无需了解网络的详细信息。过程调用有时也称为函数调用或子例程调用。
"A dear child has many names"。 RPC、Soap WS、REST、RMI 和其他只是计算机之间通信的不同方式，它们有很多相似之处，无论您选择哪一种，都可以达到相同的最终结果。在这种情况下 (grpc)，RPC 只是一个通用的 "Remote Procedure Call" 名称，表明它的用途。
选择其中一项技术时，您需要了解其中的差异，例如，RMI 作为一项仅 Java 的技术，当您不在full-Java 环境（即使那样我也不会去尝试）。如果你真的喜欢 SOAP and/or XML，你可能想要使用常规的网络服务。如果您更喜欢 JSON 而不是 HTTP，那么 REST 可能是您的选择。如果您想追求前沿技术，您可能需要选择 grpc 或其他类似技术。
使用的技术通常由现有代码库决定，因此如果您以前使用过 SOAP 网络服务，您会继续使用它。
Web 服务促进松耦合。你应该更喜欢那个。 RPC 将您限制为某种编程语言。当您使用网络服务时，您可以使用不同的语言甚至不同的操作系统来交换信息。当您考虑连接多种设备时，您应该使用 web 服务，但是当您构建具有多个模块的分布式应用程序时，也许 RPC 更合适。
What rpc can make a difference and where it is better to use ?
rpc的优点
我看到的主要优点是您被迫在编译时捕获更多错误。
这个 gRPC-Web: Moving past REST+JSON towards type-safe Web APIs 上的 post 说：
- 无需再搜索 API 文档 – .proto 是规范的 API 合同的格式，就像在其他团队中一样
- 不再 hand-crafted JSON 调用 objects – 所有请求和响应都是强类型的并且 code-generated，有可用的提示 在 IDE
- 不再处理方法、headers、body 和低级网络——一切都在 grpc-web-client
- 不再有 second-guessing HTTP 错误代码的含义 – gRPC 状态代码是 API 中表示问题的规范方式 服务器上不再有 hand-crafted chunk-encoded 流媒体疯狂 – gRPC-Web 支持 1:1 RPC 和 1:many server-side 流媒体请求
- 推出新二进制文件时不再出现数据解析错误 – 向后 forwards-compatibility 请求和响应是 由协议缓冲区保证
面向协议架构的优势
我看到的主要优势是您拥有可以在不同场景中重复使用的标准操作和通用概念。
在Richardson Maturity Model - steps toward the glory of REST中引入了不同级别的概念。您可以从那里提取一些优势。
第 1 级通过使用分而治之的方法解决处理复杂性的问题，将大型服务端点分解为多个资源。
第 2 级介绍了一组标准的动词，以便我们以相同的方式处理类似的情况，消除不必要的变化。
级别 3 引入了可发现性，提供了一种使协议更 self-documenting。
的方法什么时候使用什么？
也许 rpc 适合 in-house 当你有一个不熟悉 HTTP 或其他通用协议的领域专家团队时。它在不涉及浏览器的 backend-to-backend 通信 中也有优势。借助 gRPC 等技术，可以支持多个 languages/technologies.
之间的通信在所有其他情况下 HTTP-like 通信似乎仍然是 2017 年大多数用例的标准？
即使很久以前就有人问过这个问题，我也想添加我的简短回答，但有一些关键差异，希望对未来的读者有所帮助。
------------------------------------------------------------------------------
| Category | RPC | Web Services
------------------------------------------------------------------------------
|Operation's Location | On top of TCP | on top of HTTP Protocol
------------------------------------------------------------------------------
|Data format | Binary | Text, XML, JSON, ect.
------------------------------------------------------------------------------
|Speed | Slow (Marshilling) | Fast
------------------------------------------------------------------------------
我没有提到RPC和Web Services的描述，因为你在别人的回答中看得很清楚。