What is the difference between RPC and calling web service

Question

I just read about rpc http://www.grpc.io/ remote procedure calling, other hand we have a webservice where client send a request to server and server responds.

Same things goes with rpc where stub calls a method which is at server end. I think same things can be implemented with the help of webservice .

What rpc can make a difference and where it is better to use ?

Answer 1

RPC is a protocol that one program can use to request a service from a program located in another computer on a network without having to understand the network's details. A procedure call is also sometimes known as a function call or a subroutine call.

Answer 2

Webservices foster loose coupling. You should prefer that. RPCs limit you to a certain programming language. When you use webservices, you can have different languages and even different operating systems, that can interchange pieces of information. When you think about connecting serveral kinds of devices you should use a webservice, but when you are building a distributed application with several modules, maybe RPCs are more suitable.

Answer 3

"A dear child has many names". RPC, Soap WS, REST, RMI and others are just different ways of communicating between computers, with plenty of similarities to make it possible to reach the same end result, no matter which one you choose. In this case (grpc), the RPC is just a generic "Remote Procedure Call" name, indicating its use.

When selecting one of the technologies you need to know the differences, so for example RMI being a Java-only technology isn't something you'd want to use when not in a full-Java environment (and even then I wouldn't go for it). If you really love SOAP and/or XML , you might want to go with regular webservices. If you prefer JSON over HTTP , then REST might be your choice. If you want to go for bleeding edge, you might want to choose the grpc or other similar technology.

More often than not the technology to use would be determined by existing codebase, so if you had SOAP webservices used previously, you'd continue to use that.

Answer 4

What rpc can make a difference and where it is better to use ?

Advantages of rpc

Main advantage I see is that you're forced to catch more errors at compile time.

This post on gRPC-Web: Moving past REST+JSON towards type-safe Web APIs says:

"

• No more hunting down API documentation – .proto is the canonical format for API contracts, just like in other teams
• No more hand-crafted JSON call objects – all requests and responses are strongly typed and code-generated, with hints available in the IDE
• No more dealing with methods, headers, body and low level networking – everything is handled and abstracted away in the grpc-web-client
• No more second-guessing the meaning of HTTP error codes – gRPC status codes are a canonical way of representing issues in APIs No more hand-crafted chunk-encoded streaming madness on the server – gRPC-Web supports both 1:1 RPCs and 1:many server-side streaming requests
• No more data parse errors when rolling out new binaries – backwards and forwards-compatibility of requests and responses is guaranteed by protocol buffers

"

Advantages of protocol oriented architecture

Main advantage I see is that you have standard operations and common concepts that can be reused in different scenarios.

In Richardson Maturity Model - steps toward the glory of REST the concept of different levels is introduced. You can extract some advantages from there.

"

Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.

Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation.

Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.

"

When to use what?

Maybe rpc is good for in-house usage when you have a team of domain experts that is not familiar with HTTP or other common protocols. It has also advantages in backend-to-backend communication where no browsers are involved. With technologies like gRPC one can support communication between multi languages/technologies.

In all other cases HTTP-like communication still seems the standard for most use cases in 2017?

Answer 5

Even if the question was asked long time ago, I would like to add my short answer with key differences and hope it will be helpful for future readers.

------------------------------------------------------------------------------
| 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
------------------------------------------------------------------------------

I have not mentioned descriptions of RPC and Web Services, because you see them in others' answer clearly.