The difference between REST and RPC

1 REST

REST is not a protocol, it's an architecture. Most REST implementations use the RPC mechanism, which roughly consists of three parts:

  • method: verb (GET, POST, PUT, DELETE, etc.)
  • Host: URI (Uniform Resource Identifier), server ip, port
  • Path: noun (path, something in the server) the end of the path is the shape of the resource (such as html, text, image, pdf, etc.)

That is, method operations are performed on resources corresponding to a certain Path in the Host.

2 RPC

RPC is a technical idea rather than a specification or protocol. The usual calling process is:

1) The client serializes the function;

2) After the remote service receives it, it deserializes the function and completes the function call.

It is to call remote methods like calling local methods. Most communication protocols use binary methods, long links, and higher efficiency.

2.1 Components

The RPC architecture includes the following four components:

  • Client: service caller
  • Client stub (Client Stub): store the address information of the server, pack the request parameters of the client into a network message, and then send it to the server through the network
  • Server Stub: Accept the message sent by the client and unpack it, and then call the local service
  • Server (Server): the real service provider.

2.2 Implementation process

The specific implementation steps of RPC are as follows:

1) The service caller (client) (client) calls the service locally;

2) After receiving the call, the client stub is responsible for assembling methods, parameters, etc. into a message body that can be transmitted over the network, such as serialization in Java;

3) The client stub finds the service address and sends the message to the server through the network;

4) The server stub decodes the message after receiving it, for example, it is the process of deserialization in Java;

5) The server stub calls the local service according to the decoding result;

6) The local service executes the processing logic;

7) The local service returns the result to the server stub;

8) The server stub packs the returned result into a message, serialization in Java;

9) The server stub passes the packaged message through the network and sends it to the consumer

10) The client stub receives the message, decodes it, and deserializes it in Java;

11) The service caller (client) gets the final result.

The goal of the RPC framework is to encapsulate steps 2-10, encapsulate the process of calling, encoding/decoding, and allow users to call remote services like calling local services.

3 The difference between REST and RPC

3.1 REST

If you need to operate on service resources, you need to confirm the current status of the server first, and then send the status expected by the end user to the server after modification, and the server will modify it according to the client's expectations.

The modification code is on the client side, so the REST style client logic is more complicated than the client side. The degree of freedom is greater, but the possibility of making mistakes is also greater.

The transport layer is based on HTTP, which has an additional layer of protocol compared to TCP. However, based on HTTP transmission, it can pass through the firewall and is suitable for providing services from within the organization to outside the organization. In addition, the security of the REST interface is higher than that of RPC.

3.2 RPC

If you need to modify the resources in the service, you first need to understand the functions and calling methods of each interface in the server, and then pass the relevant parameters to the interface provided by the server, and let the server perform the modification by itself.

The code modification is on the server side, so the logic of the RPC server side is more complicated, and the server side will have a lot of workload, but the division of labor is clear and it is not easy to cause mistakes.

It can be based on TCP or HTTP. If it is based on TCP, there will be one less protocol.

3.3 Usage Scenarios

REST calls and tests are very convenient, and RPC is a bit cumbersome, but the efficiency of RPC is beyond doubt, so it is recommended to use RPC for internal calls between multiple systems. Rest is more suitable for external services.

Comparison item REST RPC
Paradigm A resource-oriented paradigm that emphasizes operating on resources represented by URIs. Method-oriented paradigm, emphasizing the remote call function, the data passed between the client and the server is realized by serializing the parameters and return values ​​of the method
letter of agreement HTTP Generally use TCP
Data Format REST transfers data using textual formats like JSON, XML etc. which are easy to read and parse RPC usually uses binary format to transfer data, such as Protobuf and MessagePack etc.
programming model REST is based on the HTTP protocol, as long as the language that can send HTTP requests and parse HTTP responses can use REST RPC supports multiple programming languages ​​and platforms such as Java, C++, Python 
performance Low high
flexibility high Low
scenes to be used
  • Provide external services
  • low frequency call
  • Intranet service call
  • IO intensive calls

3.4 Case

If you want to add 1 and subtract 1 to a number in the server database. Two different implementations are as follows:

  • REST: The server only needs one interface, the function is to change the number in the database (whether it is added or subtracted), and then the client has two functions to perform addition and subtraction operations, but the client operation is submitted to The same server-side function, and then change the database.
  • In RPC: The server should leave two interface functions, corresponding to the operation of adding 1 and subtracting 1 respectively. When the client needs to modify, it must first figure out which one is for adding 1 and which one is for subtracting 1, and then call it with parameters. Let the server change the database after adding 1 and subtracting 1.

3.5 Advantages and disadvantages

3.5.1 Advantages and disadvantages of REST

Advantages: low coupling, good compatibility, improved development efficiency, no need to care about interface implementation details, relatively more standardized, more standard, more universal, cross-language support

Disadvantage: Performance is not as high as RPC.

3.5.2 Advantages and disadvantages of RPC

advantage:

  • The call is simple, clear, and transparent, not as complicated as rest, just as simple as calling a local method.
  • Efficient and low latency, high performance
  • Custom protocol (make the transfer message smaller)
  • Low performance consumption, efficient serialization protocol can support efficient binary transmission
  • Comes with load balancing

shortcoming:

  • Strong coupling, for example: developers define their own service abstract interface for each microservice, and publish it to the private warehouse through continuous integration. The caller application has a strong dependency on the abstract interface provided by the microservice, so regardless of development, Both testing and integration environments require strict management of version dependencies, so that there will be no series of problems such as inconsistencies between the server and the caller that cause the application to fail to compile successfully, and this will also directly affect the environmental requirements of local development, often relying on many services The upper-level application of the application needs to update a lot of code every day and install it before subsequent development can be carried out. Without a strict version management system or the development of some automated tools, such dependencies can become a major nightmare for development teams. Compared with RPC, the REST interface is more lightweight. The service provider and the caller rely only on a paper contract, and there is no strong dependency at the code level. Of course, the REST interface also has pain points, because the interface definition is too light, it is easy to lead to definition documents. The inconsistency with the actual implementation leads to problems in service integration, but this problem is easy to solve. You only need to integrate swagger through each service and integrate the code and documents of each service to solve it. Therefore, in a distributed environment, REST-based service dependencies are more flexible than RPC-based dependencies.
  • Not cross-language, platform-sensitive, RPC microservices written in Java cannot be called by Python. Need to implement another layer of REST to provide external services


 

Guess you like

Origin blog.csdn.net/ygq13572549874/article/details/131797887