Restful vs RPC

Traditional RPC is generally based on binary protocols. The client sends a binary packet (and then blocks), the server processes and replies with a packet, and the client wakes up after receiving it. In the binary protocol, an id can generally be added to the packet to indicate the correspondence between the reply and the request, so that we can initiate multiple requests and replies on a tcp connection at the same time. The text protocol of HTTP can also add an id, but due to For some reasons (Content-Length may be missing), even if an id is added, multiple HTTP messages cannot be uploaded on one connection at the same time, so the HTTP protocol generally maintains multiple connections with the server, and each connection has at most one HTTP message at the same time . This "connection pool" method is called "Keep-alive" in HTTP. So even on HTTP (or any protocol), we can still efficiently send a request, block, wait for the server to finish processing, and then wake up. Isn't that what RPC is. So the choice here is more about balancing functionality and performance. In general, try to use Restful HTTP for end-users. The reason is that the cognition is wide and intuitive, all programming languages ​​support HTTP (including shell, which is convenient for debugging), performance is not so important, and it is convenient for users to share links. For internal systems, if there are not many machines, you can consider using Restful HTTP. If there are many machines, try to use binary RPC. After all, the performance gap is still very large.

The data structure of ordinary http requests is simple, and then it is stateless and does not maintain long-term connections. At the same time, because http includes a header, it will transmit a few more bytes, resulting in poor optimization.

There have been many articles about the introduction of REST, here is only an introduction to the RPC part:

What is RPC (Remote Procedure Call)

    In short, RPC is to call another machine (client) by passing parameters from one machine A function or method (which can be collectively referred to as a service) on a machine (server) and get the result returned.
    RPC will hide the underlying communication details (no need to deal with Socket communication or Http communication directly)
    RPC is a request-response model. The client initiates a request, and the server returns a response (similar to how Http works).
    RPC is used to call a remote function (or method) in the same way as calling a local function (or method).

Remote Procedure Call Development History

    ONC RPC (Remote Procedure Call for Open Network Computing), OSF RPC (Open Software Foundation's Remote Procedure Call)
    CORBA (Common Object Request Broker Architecture)
    DCOM (Distributed Component Object Model) ), COM+
    Java RMI
    .NET Remoting
    XML-RPC, SOAP, Web Service
    PHPRPC, Hessian, JSON-RPC
    Microsoft WCF, WebAPI
    ZeroC Ice, Thrift, GRPC
    Hprose

Early RPC

    First Generation RPC (ONC RPC, OSF RPC) not supported object transfer.
    CORBA is too complicated, and the various implementations are incompatible, and the average programmer can't play it.
    DCOM, COM+ cannot escape the palm of Windows.
    RMI can only be played in Java.
    .NET Remoting can only be played on the .NET platform.

XML-RPC, SOAP, WebService

    has too much redundant data and the processing speed is too slow.
    RPC-style Web Services are poorly cross-language, and Document-style Web Services are too difficult to use.
    Web services don't solve the user's real problem, they just turn one problem into another.
    The specification for Web Services is so complex that there is no really useful, or even usable, implementation outside of the .NET and Java platforms.
    Cross-language and cross-platform is just a slogan of Web Services, although many people believe this, but in fact it does not really come true.

PHPRPC

    is based on PHP's built-in serialization format, and has flaws in cross-language type mapping.
    The communication relies on the HTTP protocol, and there is no choice of other underlying communication methods.
    The built-in encrypted transmission is both a feature and a drawback.
    While faster than XML-based RPC, it's not fast enough.

The Hessian

    binary data format is completely unreadable.
    The official only provides two and a half language implementations (Java, ActionScript and the less-than-perfect Python implementation), and third-party implementations in other languages ​​are mixed.
    Not enough languages ​​are supported, and there is a complete disregard for JavaScript on the web front end.
    Although it is a dynamic RPC, it is still not very dynamic.
    While faster than XML-based RPC, it's not fast enough.

JSON-RPC

    JSON is text-readable and more concise than XML.
    JSON is limited by a subset of the JavaScript language and cannot represent enough data types.
    The JSON format cannot represent self-references, mutual references and circular references within the data.
    Some languages ​​have multiple versions of the implementation, but there is no unified standard for type insinuation, and there are compatibility problems.
    Although JSON-RPC has a specification, there is no unified implementation. The respective implementations in different languages ​​have compatibility problems and cannot really communicate with each other.

Microsoft WCF and WebAPI

    are Microsoft's unified encapsulation of existing technologies on a .NET platform, and an integration of technologies such as .NET Remoting, WebService and REST-style services based on data formats such as JSON and XML.
    Although it claims to be able to call these services outside the .NET platform, it is actually completely different from calling within the .NET platform. It doesn't provide any tools that can be used in the languages ​​of other platforms.

ZeroC Ice, Thrift,

    the cross-language object-oriented regression of the original RPC technology of GRPC.
    Type and interface definitions still need to be written through an intermediate language.
    You still need code generators to translate type and interface definitions written in the intermediate language into client-side and server-side stubs for your programming language.
    You have to write the service separately based on the generated server code, you cannot publish the existing code directly as a service.
    You have to use the generated client code to call the service, there is no other more flexible way.
    If your intermediate code is modified, you must repeat all the above steps at least once.

Hprose has

    a non-intrusive design, does not need to define the type separately, and does not need to write the service separately, and the existing code can be directly published as a service.
    With rich data types and perfect cross-language type mapping, it supports self-reference, mutual reference and circular reference data.
    Supports many transmission methods, such as HTTP, TCP, Websocket, etc.
    The client has a more flexible calling method, supports synchronous calling, asynchronous calling, dynamic parameters, variable parameters, reference parameter passing, multiple result return (Golang) and other language features, Hprose 2.0 even supports push.
    It has good scalability, and can achieve various functional extensions such as encryption, compression, caching, and proxy through filters and middleware.
    Compatible and undifferentiated cross-language calls
    Support more common languages ​​and platforms
    Support cross-domain calls on the browser side
    No intermediate language, no learning cost
    , high performance, easy to use