RPC protocol Learning (3) differences from other

RPC protocol Learning (3) differences from other
Summary

The Web Service is no longer fresh, and the subsequent SOA and Cloud Computing are also emerging until Baidu also proposed its own box Computing, we still don't care how much actual technological innovation is behind these fashionable terms, but they cannot escape a little, that is, how to solve the problem of service access, the service here is usually not local, but in the distant us or India that you don't know.

This article describes the two methods mentioned in the title to address remote service access, their advantages and disadvantages, and some practical suggestions.

Contents

• Summary
• Introduction
• Web Service
• RPC
• REST
• Differences between RPC and REST
• How to choose?
• An example of your own project
• Conclusion
• References
• Rst source code in this article

Introduction

Every day, we use browsers to surf the Internet and find the resources we need. The HTTP protocol is naturally the one we use most. We enjoy the pleasure of this information highway, but didn't try to understand how we got these resources? What kind of design concept is it?

We also occasionally use Gtalk to chat with our colleagues or friends. While providing resources (information) to our friends, we also get resources (information) from our friends ), have we ever wondered what process is behind this communication?

In this Internet era, as long as it involves obtaining non-local resources, it will face a problem:

How to access the service?

Let's first look at what is Web Service.

Web Service

Web Service has been proposed for a long time. So what is Web Service?

In short, that is, how the server provides services to the client.

Common methods include:

1. RPC Remote Procedure Call (method-oriented)
2. SOA's so-called Service-Oriented Architecture (message-oriented)
3. REST the so-called Representational state transfer (Resource-Oriented)

SOA is a popular term in the past few years. It is no less powerful than the current Cloud Computing. If RPC is based on method, SOA is based on messages, method-based calling is usually coupled with a specific program language, which is irrelevant to the specific implementation language, so it is supported by a large company to a certain extent.

This article will not write too much on SOA, mainly because I have not studied much about it, so I am afraid to mislead readers. in addition, I have recently studied the principles and implementation of RPC and REST methods, so this article will focus on RPC and REST.

RPC

RPC is a simple concept of Remote Process calling. It calls the server's Service (method) Just like calling a local service (method ).

Usually the implementation of XML-RPC, JSON-RPC, communication methods are basically the same, the difference is only the format of data transmission.

(If you are used to the heavy angle brackets of XML, you can try JSON with lighter, more efficient, and more efficient transmission .)

A simple communication process is usually:

Request

<?xml version="1.0"?> <methodCall> <methodName>member.get_username_by_id</methodName> <params> <param> <value><i4>1</i4></value> </param> </params> </methodCall> 

Response

<?xml version="1.0"?> <methodResponse> <params> <param> <value><string>Zhu Tao</string></value> </param> </params> </methodResponse> 

Send the method and its parameters of a process call to the server to obtain the execution result of the method returned by the server.

After the XML-RPC, there is more powerful SOAP for some more complex systems.

REST

Finally, let's look at REST. Haha, this is my favorite remote communication method (Architecture ).

REST is not a protocol. It is an architecture. If a Web Service can meet the REST conditions, it is usually calledRestful.

The conditions mentioned here include:

1. C/S structure (a basic feature of Internet services)
2. Stateless (very familiar, huh, huh)
3. Cache (remember the browser ?)
4. Layered System (think of countless architectures ?)
5. Unified interface (if this is possible, the programmer is blessed: D)
6. Code on demand (optional, in fact, a requirement for scalability)

HTTP is the core protocol of WWW. It unifies resources distributed in every corner of the world, and provides a uniform address, a simple method, and a certain number of expressions. (You may have vague descriptions of these three points, please go ahead ).

The three elements of REST are unique resource identifiers. Simple methods (the methods here are abstract concepts) have certain expressions.

See:

Figure 1. triangle structure of REST (from Restful User Experience)

REST is a resource-centric term, that is, the address of resources. verbs are limited operations applied to nouns, and expressions are the abstraction of various resource forms.

Taking HTTP as an example, the term URI (Uniform Resource Identifier) includes POST, GET, PUT, DELETE, and so on (there are two other commonly used, therefore, the entire verb set is limited. The resource format (such as text, html, image, and pdf)

Differences between RPC and REST

If you only want to remember one thing, remember that RPC is verb-centered, REST is noun-centered, and verbs here refer to some methods, and nouns refer to resources.

You will find that verb-centered, meaning that when you want to add new features, you must add more verbs. At this time, the server must implement the corresponding verbs (methods ), the client needs to know the new verb and call it.

However, if the request is hostname/friends/, no matter how the service corresponding to this URI changes, the client does not need to pay attention to or update it, this change is transparent to the client.

Other differences, such as dependency on the implementation Language and coupling, are derived from the fundamental difference mentioned above.

Let's go back to the two introduced questions. when you use HTTP surfing every day, you are using REST to make close contact with remote servers. when you use Gtalk to communicate with colleagues and friends, you enjoy RPC convenience.

Read Restful User Experience (this slide is the best I personally think) and ReST vs SOA (P ).

How to choose?

Generally, if we are a client, we basically have no right to choose. Service providers usually have only one architecture of services. for example, facebook, Renren open API (using REST ).

But if we are lucky enough to design and implement our own Web Service, how should we choose?

Based on my own experience and experience, we suggest using REST as much as possible, mainly based on the following considerations:

1. Scalability
2. Loose coupling (meaning that the client is not required to update the corresponding code)
3. Client implementation language independence
4. Performance
5. Security (such as HTTPS)

Of course, none of the above mentioned RPC is satisfied, but REST is relatively clearer and concise, and the corresponding JSON service will provide performance and stability (simple usually means robust) this has greatly improved.

An example of your own project

Our company is working on a social game project. I am responsible for the back-end architecture and communication of the entire system, so I carefully studied and studied the APIS opened by facebook/Renren, because facebook (Renren completely copies facebook) uses a REST architecture, even if facebook is developed in PHP, this does not prevent us from using python for development, there are more PHP, Java ,.. net, Perl, and other client API encapsulation. (Of course Renren is developed using Java, and we also use python ).

So I was wondering if facebook's architecture was not REST, would it be so flexible? If RPC is used, it may be difficult for us to establish projects!

In addition, because our front-end uses flash and uses djangoamf to communicate with the backend python, it is interesting that if you know about flash, you will know that AMF is a binary flash data interaction protocol, and it is based on RPC! Of course, as I mentioned above, some architectures are not available for us to choose from, so the result of using RPC is that if we want to open our game APIs (if our games are hot enough, some friends want to develop peripheral applications based on our games), which makes it very difficult. but at present, we are unlikely to open APIs.

Conclusion

Whether based on verbs, terms, or messages, these services provide us with a stable, reliable, secure, and scalable service. Therefore, if you have the opportunity to provide open APIs for other clients (If your company is another facebook or twitter Company), you may wish to consider more developers based on your platform, don't make them difficult.