The difference between RPC and restful

RPC

RPC and RESTful Are remote call interfaces , So what is the difference between them ？ I used to be confused , Until I read what teacher zhouzhiming wrote 《 Phoenix Architecture ： Building reliable large-scale distributed systems 》 I just figured out the difference between them , I'm afraid I forget , Take special notes .

RPC（Remote Procedure Call,RPC）, Remote procedure call , In recent years, it has been frequently used in various forums , article , Course mention , At first glance, I thought it was some awesome new technology , In fact, it has existed in computer science for more than 40 years , It's a true “ Antique ”.

RPC The original purpose of emergence , This is to enable the computer to call remote methods just as it calls local methods .

Let's first take a look at how the computer calls this place , I copied the examples in the book ：
// Caller : caller , In code main()
// Callee ： Callees , In code println()
// Call Site ： Calling point , That is, the position of the instruction stream where the method call occurs
// Parameter ： Parameters , from Caller Pass to Callee The data of , namely “hello world”
// Retval ： Return value , from Callee Pass to Caller The data of , If the method ends normally , It is void, If the method completes abnormally , It is the corresponding exception

public static void main(String[] args) {
        
System.out.println("hello world");
}

Without considering compiler optimization at all , The program runs to call println() Method output hello world In this business , Computer （ Physical or virtual machines ） To complete the following tasks .

1. Pass method parameters ：
   The string hello world The reference address of the stack .
2. Determine the method version ：
   according to println() Method signature , Determine its execution version . This is not a simple process , Whether it is static parsing at compile time , Or runtime dynamic dispatch , Must be based on principles clearly defined in certain language specifications , Find a definite Callee,“ clear ” It means the only one Callee, Or multiple with strict priority Callee, For example, different overloaded versions .
3. Execute the called method ：
   Pop out of the stack Parameter The value or quotation of , And use this as input , perform Callee Internal logic . Here we only care about how the method is called , And don't care about how the method is executed .
4. Return execution result ：
   take Callee Stack the execution results of , And restore the instruction flow of the program to Call Site Next instruction for , Keep going down .

Let's consider again if println() Method is not in the memory address space of the current process . It's not hard to imagine. , There are at least two immediate obstacles to this .

First , The transfer parameters done in the first and fourth steps 、 The returned results depend on the stack memory , If Caller And Callee Belong to different processes , You won't have the same stack memory , The parameter is displayed in the Caller The memory stack of the process , about Callee The implementation of the process is meaningless .

secondly , The method version selection in the second step depends on the language rules , If Caller And Callee Programs that are not implemented in the same language , Method version selection would be a fuzzy, agnostic behavior .

Let's ignore the second question for the time being , hypothesis Caller and Callee It is implemented in the same language . So how do two processes exchange data ？ This is it. “ Interprocess communication ”（Inter-Process Communication,IPC） The problem to be solved .

Several solutions for interprocess communication ：

The Conduit （Pipe） Or named pipeline （Named Pipe）

A pipeline is like a bridge between two processes , A small number of character streams or byte streams can be passed between processes through pipelines . Common pipes are only used for related processes （ Another process started by one process ） Communication between , Named pipeline gets rid of the limitation that ordinary pipeline has no name , In addition to having all the functions of the pipeline , It also allows communication between unrelated processes .

The typical application of pipeline is... In the command line “|” The operator ,
for example ：ps -ef | grep java
ps And grep There are independent processes , The above command is through the pipeline operator “|” take ps The standard output of the command is connected to grep The standard input of the command .

The signal （Signal）

Signals are used to inform the target process that an event has occurred . In addition to interprocess communication , The process can also send signals to the process itself . Typical applications of signals are kill command ,
for example ：kill -9 pid
The above command means that Shell The process specifies to the PID The process of sending SIGKILL The signal .

Semaphore （Semaphore）

Semaphores are used to synchronize collaboration means between two processes , It is equivalent to a special variable provided by the operating system , The program can be carried out on it wait() and notify() operation .

Message queue （Message Queue）

The above three methods are only suitable for delivering a small number of messages ,POSIX The standard defines a message queue that can be used for communication with a large amount of data between processes . The process can add messages to the queue , A process that is granted read permission can also consume messages from the queue . Message queuing overcomes the lack of signal carrying information 、 Pipeline can only be used for unformatted byte stream and buffer size limitation , But the real-time performance is relatively limited .

Shared memory （Shared Memory）

Allow multiple processes to access the same common memory space , This is the most efficient form of interprocess communication . Originally, the memory address space of each process is isolated from each other , But the operating system provides a way for the process to actively create 、 mapping 、 Separate 、 A program interface that controls a block of memory . When a piece of memory is shared by multiple processes , Processes often interact with other communication mechanisms , For example, in combination with semaphores , To achieve the coordinated operation of inter process synchronization and mutual exclusion .

Local socket interface （IPC Socket）

Message queue and shared memory are only suitable for communication between single machine and multi process , Socket interface is a more universal inter process communication mechanism , It can be used for process communication between different machines . Socket （Socket） At first it was by UNIX Systematic BSD Branch developed , Now it has been transplanted to all mainstream operating systems . For efficiency , When limited to native interprocess communication , The socket interface is optimized , Will not pass through the network protocol stack , No need to pack and unpack 、 Calculate the check sum 、 Maintain serial number and response , Simply copy application layer data from one process to another , This way of interprocess communication is called local socket interface （UNIX Domain Socket）, It's also called IPC Socket.

RPC Three problems to be solved

How to represent data

The data here includes the parameters passed to the method and the return value after the method is executed . That is, one process passes parameters to another process , Or get the return value from another process , How to express the data format . You may find it strange , For example, use Java Program written in language , Pass on String,int Just wait for the type ？ For in-process method calls , Data types in the same language , For example, both parties' procedures use Java Written language , There is no problem with this call . however , If the caller uses Java Written language , Callee is C Written language , Their data types are defined differently , How to be compatible ？

Even if both sides are written in the same language , such as C Language , But in different hardware instruction sets 、 Under different operating systems , The same data type may also have different performance details , For example, data width 、 Differences in byte sequences, etc .

So what should we do ？

It's easy to say , That is, first convert the data to be exchanged between the two sides into an intermediate format that everyone knows , Then convert the intermediate format data into the data type of your own language , Does it sound familiar ？ you 're right , This is serialization and deserialization . I used to learn Java When , Learning serialization and deserialization makes me wonder ？ Why should parameters be serialized ？ Just pass it directly ？ It turns out that different languages should be considered 、 Hardware 、 Operating system .

Each of these RPC All protocols have corresponding serialization protocols , for example ：

• ONC RPC External data representation of （External Data Representation,XDR）
• CORBA Universal data representation （Common Data Representation,CDR）
• Java RMI Of Java Object serialization stream protocol （Java Object Serialization Stream Protocol）
• gRPC Of Protocol Buffers
• Web Service Of XML serialize
• Many lightweight RPC Supported by JSON serialize

notice Web Service Of XML Serialization is particularly touching , Used to use Web Service When , I wonder why I use xml It takes so much effort to describe the fields , Parameter by parameter , It was to make different languages recognizable .

How to pass data

How to transfer data between two programs , That is, they operate with each other , Interactive data , In addition to serialization and deserialization, you also need to consider ： abnormal 、 Overtime 、 Security 、 authentication 、 to grant authorization 、 Business and so on , Both sides may need to exchange information . In computer science , There is a special noun “Wire Protocol” To express these two Endpoint The act of exchanging such data between , common Wire Protocol as follows ：

• Java RMI Of Java Remote message exchange protocol （Java Remote Message Protocol,JRMP, Also support RMI-IIOP）
• CORBA Internet ORB An agreement between the two （Internet Inter ORB Protocol,IIOP, yes GIOP The agreement IP Implementation version on the protocol ）
• DDS Real time publish subscribe protocol （Real Time Publish Subscribe Protocol,RTPS）
• Web Service Simple object access protocol （Simple Object Access Protocol,SOAP）
• If the requirements are simple enough , Both sides HTTP Endpoint, Use it directly HTTP The agreement is also possible （ Such as JSON-RPC）

In addition to passing data ,RPC There are more attractive places , What makes it really powerful is its governance function , For example, connection management 、 Health detection 、 Load balancing 、 Elegant start stop 、 Exception retry 、 Business grouping, fuse current limiting, etc .

How to express methods

Make sure that the presentation method is not a big problem in local method calls , The compiler or interpreter will follow the language specification , Convert the method signature of the call to a pointer to the entry position of the sub process in the process space . But once you have to consider different languages , Things immediately got into trouble again , Method signatures can vary from language to language , therefore “ How to represent the same method ”“ How to find the corresponding method ” We still need a unified cross language standard .

This standard can be very simple , For example, each method of the program is directly specified with a unique 、 Never repeat the number on any machine , When called, it doesn't matter what method it is 、 How signature is defined , Directly pass this number to find the corresponding method . This approach sounds rude and shabby , It's really DCE/RPC The original solution . Although in the end DCE Or did you come up with a language independent interface description language （Interface Description Language,IDL）, Since then many RPC The basis of reference or dependence （ Such as CORBA Of OMG IDL）, But the only coding scheme that never repeats UUID（Universally Unique Identifier） It is also preserved and widely spread , And is widely used in all aspects of program development .

Similarly , There are also protocols for representing methods ：

• Android Of Android Interface definition language （Android Interface Definition Language,AIDL）
• CORBA Of OMG Interface definition language （OMG Interface Definition Language,OMG IDL）
• Web Service Of Web Service description language （Web Service Description Language,WSDL）
• JSON-RPC Of JSON Web The service agreement （JSON Web Service Protocol,JSON-WSP）

above RPC Three basic problems in , All of them can find corresponding solutions in the local method calling process .RPC The design of starts with local method calls , Although there is no longer a desire to achieve exactly the same goal as local method calls , But its design idea is still deeply branded with local method invocation , Grasp the connection between the two to draw an analogy , A deeper understanding of us RPC The nature of would be helpful .

In order to solve the above three problems , Every RPC Our products solve problems from different angles , Some focus on simplicity , Some hope to support more languages to achieve universality , Some prefer high performance . Now? , Have appeared one after another RMI（Sun/Oracle）、Thrift（Facebook/Apache）、Dubbo（ Alibaba /Apache）、gRPC（Google）、Motan1/2（ Sina ）、Finagle（Twitter）、brpc（ Baidu /Apache）、.NET Remoting（ Microsoft ）、Arvo（Hadoop）、JSON-RPC 2.0（ Open specification ,JSON-RPC Working group ） And other inexhaustible protocols and frameworks . these RPC function 、 Different characteristics , There are some languages , Some support multiple languages , Some run in the application layer HTTP The agreement above , Some run directly on the transport layer TCP/UDP The agreement above , But there is no one that is “ The most perfect RPC”.

Today and now , Any one with vitality RPC frame , No longer pursue big and complete “ perfect ”, But take a targeted feature as the main development direction . At the same time, it also leads to our choice difficulty , It also gave birth to a large number of online articles and courses , To explain each RPC Advantages and disadvantages , When can there be one RPC The king of came out to unify the world ？

REST

REST From the Roy Thomas Fielding stay 2000 Doctoral dissertation published in “Architectural Styles and the Design of Network-based Software Architectures”, This article is indeed REST The source of .REST（Representational State Transfer, Characterization state transfer ）, The name sounds very obscure , What do you mean “ characterization ”、 What is it “ state ”、 From where “ Transfer ” Where to ？

We need to understand REST We must first understand what is HTTP, With some practical examples, we can make an analogy between the two , To better understand REST, You'll find that REST It's actually “HTT”（Hypertext Transfer） Further abstraction of , The relationship between the two is like the relationship between the interface and the implementation class .

Hypertext （ Or hypermedia ）

“ Hypertext （ Or hypermedia ）” It's a kind of “ Text that can judge and respond to operations （ Or sound 、 Image, etc ）”, The concept of 20 century 60 When the s was put forward, it should still belong to the category of science fiction , But today the public has fully accepted it , A paragraph of text on the Internet can be clicked 、 Can trigger script execution 、 It is no wonder that the server can be called . Let's continue to try from “ Hypertext ” perhaps “ Hypermedia ” To understand what is “ characterization ” as well as REST Other key concepts in , Here, a specific example is used to describe it as follows ：

resources （Resource）

For example, you are reading an article entitled 《REST Design style 》 The article , The content of this article itself （ You can understand it as the information contained 、 data ） be called “ resources ”. Whether you buy books through reading 、 The web page on the browser is still a printed document , Whether reading on a computer screen or on a mobile phone , Although the appearance is different , But the information is constant , What you read is still the same “ resources ”.

characterization （Representation）

When you read this article through your browser , The browser will send... To the server “ I need this resource HTML Format ” Request , This returned by the server to the browser HTML This is called “ characterization ”, You can also get this article in other ways PDF、Markdown、RSS Other forms of version , They are also multiple representations of a resource . so “ characterization ” It refers to the representation of information when interacting with users , This is different from what we often say in software layered architecture “ The presentation layer ”（Presentation Layer） The semantics of are actually consistent .

state （State）

When you finish reading this article , When you want to see what's next , You send... To the server “ Give me the next article ” Request . however “ Next ” It's a relative concept , Must depend on “ Which article are you currently reading ” In order to respond correctly , This kind of contextual information that can only be generated in a specific context is called “ state ”. What we call stateful （Stateful） Or stateless （Stateless）, They are only relative to the server , The server should complete “ Take down one ” Request , Or remember the user's status , For example, what article is this user reading now , This is called stateful ; Either the client remembers the State , Clearly tell the server when requesting , If I'm reading an article , Now I'm going to read its next article , This is called statelessness . in other words , The server records the user's status, which is called stateful ; The status is recorded by the client , And send it to the server called stateless .

Transfer （Transfer）

Whether the state is provided by the server or the client ,“ Take down an article ” This behavior logic can only be provided by the server , Because only the server has the resource and its representation . The server uses some way , hold “ The article the user is currently reading ” Into a “ Next article ”, This is called “ Characterization state transfer ”.

REST A core principle of is “ Unified interface （Uniform Interface）”,REST I hope developers can program for resources , I hope the focus of software system design is on what resources the abstract system should have , Instead of abstracting what the system should do （ service ） On . You can understand this principle by analogy with the operation of file management in a computer , Managing files may involve creating 、 modify 、 Delete 、 Moving and so on , The number of these operations is countable , And it is fixed to all files 、 A unified . If you design a system for resources , It will also have similar operating characteristics , because REST No new protocol was designed , So these operations borrow HTTP Operation commands inherent in the protocol to complete .

So is the unified interface REST The most controversial place , Network based software system , Is it resource oriented , Or service orientation is more appropriate , I'm afraid there will be no final conclusion on this issue for a long time , Maybe never . however , There has been a basically clear conclusion that ： Resource oriented programming is usually more abstract . The disadvantage of a high degree of abstraction is that it is often farther away from the human way of thinking , The advantage is that the degree of generality is often better .

Use such language to interpret REST, It's still a little abstract , Here's an example ： for example , There are login and logout functions for almost every system , If you understand that login corresponds to login() service , Logout corresponds to logout() Services are two independent services , This is a “ In line with human thinking ” Of ; If you understand that login is PUT Session, Logout is DELETE Session, So you just need to design one “Session resources ” To meet the needs , Even later on Session Other needs of , For example, query the login user's information , Namely GET Session nothing more , Other operations such as modifying user information can also be included in the same design , This is “ More abstract ” Benefits .

If you want to make rational and appropriate use of unified interfaces in architecture design , It is suggested that the system should be able to include resources in each request ID, All operations are performed through resources ID To carry out ; It is recommended that each resource should be a self describing message ; It is suggested to drive the transfer of application state through hypertext .

REST Bound to HTTP agreement . Resource oriented programming does not have to be built on HTTP above , but REST yes , This is a disadvantage , And advantages . because HTTP It is originally a network protocol for resource design , Just use HTTP（ instead of SOAP over HTTP Then build the agreement ） The benefit is that there is no need to consider RPC Medium Wire Protocol problem ,REST Will be reused HTTP The concepts defined in the protocol and related basic support to solve the problem .HTTP The agreement has been in effect for thirty years , The relevant technical infrastructure has been tempered , Incomparably mature . The downside is, of course , When you want to think about those HTTP When features are not provided , Will be completely helpless .

HTTP A set of has been agreed in advance in the agreement “ Unified interface ”, It includes GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS Seven basic operations , Any support HTTP All servers of the protocol will comply with this set of regulations , For specific URI Take these actions , The server will trigger the corresponding token state transition .

REST The interface is easy to understand , For example , Suppose the interface design of a mall User Center ： User resources have multiple subordinate resources , For example, several short message resources 、 A user profile resource 、 A shopping cart resource , The shopping cart will have its own subordinate resources , For example, multiple book resources . You can easily construct the collection and hierarchy of these resources in the program interface , And these relationships are in line with people's long-term experience of managing data in a stand-alone or network environment . I believe you don't need to read the interface specification , It's easy to infer that getting users icyfenix Of the shopping cart 2 Of this book REST The interface should be represented as ：
GET /users/icyfenix/cart/2.

Let me give you a few more examples ：

• GET /books： List all the books
• POST /books： Create a new book
• GET /books/ID： Get information about a given book
• PUT /books/ID： Update information about a Book （ Provide full information about the book ）
• PATCH /books/ID： Update information about a specific book （ Provide some information about the book ）
• DELETE /books/ID： Delete a Book

RPC and RESTful The difference between

A lot of people will take REST And RPC Comparison , Actually ,REST Whether in thought 、 Conceptually , Still in the scope of use , And RPC It's all different , At best, there are some similarities , There will be some overlap in the application , But it's not the same kind of thing in essence .

RPC and REST The core of the difference in thinking is that the abstract goals are different , That is, the difference between process oriented programming and resource oriented programming .

REST And RPC Conceptual differences refer to REST Is not a remote service invocation protocol , You can even get rid of the attributive , It is not an agreement . The agreements are normative and mandatory , At least there is a specification document , for example JSON-RPC, No matter how simple , Also have 《JSON-RPC standard 》 To specify the format details of the agreement 、 abnormal 、 Response code and other information , however REST These are not defined , Despite some guidelines , But in fact, it is not bound by any compulsion . Some people often criticize a system interface “ Not designed enough RESTful”, In fact, this sentence itself is somewhat controversial ,REST It can only be said that it is style rather than norm 、 agreement , And can fully comply with REST Systems of all guiding principles are also rare .

REST The basic idea of is to abstract problems facing resources , It is similar to the previous popular programming ideas —— Process oriented programming is fundamentally different in abstract subjects . stay REST Before putting forward , The only way people can design distributed system services is RPC,RPC It is to transfer the local method invocation idea to the remote method invocation , Developers are centered around “ Remote method ” To design the interaction between the two systems , for example CORBA、RMI、DCOM, wait . The disadvantage of doing so is not only that “ How to represent a method between heterogeneous systems ”“ How to obtain the method list that the interface can provide ” Become a problem that needs special agreement to solve （RPC One of the three basic problems of ）, And for service consumers , Because each method of the service is completely independent , They must learn one by one to use these methods correctly .Google stay “Google API Design Guide” Once wrote such a passage in .

“ before , People design for methods RPC API, for example CORBA and DCOM, Over time , There are more and more interfaces and methods, but they are different , Developers must understand each method to use them correctly , This is time-consuming and error prone .”

in other words RPC The client must know the server-side methods before calling them .

We're calling Web Service The interface should be provided by the server before WSDL File to generate the client , Client pass WSDL The file knows the methods and parameters of the server .

Again gRPC There are also servers and clients ,gRPC The call example diagram of is as follows ：

Let's take a look gRPC Code for .

Server side ：

  /** *  External exposure services  **/
  private void start() throws IOException {
    
    int port = 50051;
    server = ServerBuilder.forPort(port)
        .addService(new HelloServiceImpl())
        .build()
        .start();
    Runtime.getRuntime().addShutdownHook(new Thread() {
    
      @Override
      public void run() {
    
        HelloWorldServer.this.stop();
      }
    });
  }

client ：

  /** *  send out rpc request  **/
    public void say(String name) {
    
        //  Build the parameter object 
        HelloRequest request = HelloRequest.newBuilder().setName(name).build();
        HelloReply response;
        try {
    
            //  Send a request 
            response = blockingStub.say(request);
        } catch (StatusRuntimeException e) {
    
            return;
        }
        System.out.println(response);
    }

The client must first know the server say() Method , To call it .

REST It is operated according to resources , If REST The design of meets the requirements of article 3 Level maturity ：Hypermedia Controls（ Hypertext driven ）, The server will return a hyperlink for the next operation . Except that the first request is driven by the information you enter in the browser address bar , Other requests should be able to describe the possible subsequent state transitions , Driven by hypertext itself .

Let's take a look at the examples in the book ：

HTTP/1.1 200 OK

{
    
    schedules：[
        {
    
            id: 1234, start:"14:00", end: "14:50", doctor: "mjones",
            links: [
                {
    rel: "comfirm schedule", href: "/schedules/1234"}
            ]
        },
        {
    
            id: 5678, start:"16:00", end: "16:50", doctor: "mjones",
            links: [
                {
    rel: "comfirm schedule", href: "/schedules/5678"}
            ]
        }
   ],
   links: [
       {
    rel: "doctor info", href: "/doctors/mjones/info"}
   ]
}

Even if the server does not return a link to the next operation , After the client knows the resource, it can even guess the next operation URL.

summary

RPC It calls remote methods in a way of calling local methods , Through a variety of RPC The framework hides the details of invoking remote methods , Let the user think that what is called is a local method .RPC It hides the complexity of the underlying network communication , Let's focus more on the development of business logic .

REST adopt HTTP Realization , Abstract user requirements into resource operations , The user has to go through HTTP Agreed GET、HEAD、POST、PUT、DELETE、TRACE、OPTIONS Seven basic operations to interact with the server .

RPC Usually server to server communication , For example, communication with middleware ,MQ、 Distributed cache 、 Distributed database and so on .

and REST It is usually client-side （ It's usually a browser ）, Their usage scenarios are also different .

Last , I would like to recommend Mr. zhouzhiming's 《 Phoenix Architecture ： Building reliable large-scale distributed systems 》, Most of the contents of this article are copied from this book .