This journey called life, there are too many scenery to review
Recently, I accidentally saw a technical post when I was chatting. The topic of discussion was probably: “Is RPC or RESTFUL better in Web development?” (It is a very old topic). Since I have only used restful in web development before, the answer to this question is not clear in itself, so I checked the information with a learning attitude and felt it necessary to record it here afterwards.
REST stands for representational state transfer. REST is about the relationship between the client and the server. The server needs to provide descriptive data in a simple format. Commonly used is JSON and XML.
RPC-based APIs apply to actions (procedures, commands, etc.); REST-based APIs apply to domain models (resources or entities), data-based CRUD (create, read, update, delete) operations.
An interface call usually consists of two parts, a serialization and a communication protocol. Common serialization protocols include json, xml, hession, protobuf, thrift, text, bytes, etc. Communication is popular with http, soap, and websockect. RPC is usually based on TCP. Then the serialization protocol used by restful is usually json, the communication protocol is http; rpc is a communication protocol, so if serialization uses json, then it is json-rpc.
Daniel 1: Restful first requires that all applications be defined as “resource” and then only four operations can be done for the resource. However, all interfaces, the server side originally has corresponding functions, they have their own namespace, accepted parameters, return values, exceptions and so on. It only needs to be exposed in a light way. It is not necessary to re-integrate a bunch of functions into “resources”, and then cut the brain to map all operations to “additions, deletions and changes”.
Daniel 3: http is relatively more standardized, standard, and universal, regardless of which language supports http protocol. The performance of the RPC protocol is much higher, such as Protobuf, Thrift, Kyro, etc. RESTful is recommended for APIs that are open to the world, and strict compliance with specifications is a trade-off. To integrate cost, stability, ease of use, business scenarios and many other factors. The internal call is recommended to use the RPC method. Of course, it cannot be generalized, but also depends on the specific business scenario.
The source of the above answer:
Next, talk about personal insights~! ~, well, I don’t have any insights at the moment. Let me use it myself to see the rpc protocol.
Zerorpc is a remote procedure call protocol (RPC) implementation based on ZeroMQ and MessagePack. The Service API used with Zerorpc is called zeroservice. Zerorpc can be called programmatically or via the command line.
The official demo.py is as follows:
Run the above code:
Analysis: From the point of view of the demo, remotely through the rpc protocol (tcp) for function calls! ! ! This operation is still a bit 666, because the use of restful can only operate on resources or data, and the rpc protocol directly operates on functions, and the code is simple.
Refer to github: https://github.com/dotcloud/zerorpc-python
Simply put, personal understanding, personally think that rpc and restful itself are different in orientation, restful biased resources or data communication, pay attention to interface normative, in short, more general; rpc protocol is used for service function calls, specifically It is the call of a function that can be adapted to scenarios with more complex communication needs. Therefore, I still agree with the above statement of a big cow. You can choose to use rpc internally, because of the performance advantage and other reasons, and use resutful externally, because it is universal.