All content of this blog is licensed under Creative Commons Licenses . When citing this content, please keep Zhu Tao , the source , and non-commercial.
1. Abstract
Web Service is no longer new, and the subsequent SOA and Cloud Computing have continued to appear until Baidu also proposed its own box computing. We don’t care how many actual technological innovations are hidden behind these fashionable terms, but they are after all. There's no escaping one point, and that's how to solve the problem of accessing services, which are usually not local but far away in the US or India you don't know.
This article would like to describe the two methods mentioned in the title to solve remote service access, their advantages and disadvantages, and some practical suggestions.
2. Introduce
We use browsers to surf the Internet every day to find the resources we need. The HTTP protocol is naturally the one we use the most. We enjoy the thrill of this information highway without trying to understand who we are. How to get these resources? What kind of design concept is it?
We also occasionally use Gtalk to chat with our colleagues or friends. While we provide resources (information) to friends, we also obtain resources (information) from friends. Have we ever thought about this kind of communication? What kind of process?
In this era of the Internet, as long as it involves obtaining non-local resources, there will be a problem:
How to access the service?
Let's first see what a Web Service is .
3. Web Service
Web Service has also been proposed for a long time, so what exactly is a Web Service?
Simply put, it is how the server provides services to the client. Commonly used methods are:
1.RPC so-called remote procedure call (method-oriented)
2. SOA so-called service-oriented architecture (message-oriented)
3.REST so-called Representational state transfer (resource-oriented)
SOA is a very popular word in the past few years. It is no less than the current Cloud Computing. If RPC is based on method calls, then SOA is based on messages. Based on method calls, it is usually coupled with a specific programming language. The latter is independent of the specific implementation language, so it is supported by large companies to a certain extent.
4. RPC
RPC stands for Remote Procedure Call, a very simple concept. It calls the server's service (method) like calling a local service (method). The usual implementations include XML-RPC and JSON-RPC. The communication method is basically the same, the only difference is the transmission of data. format. (If you're used to XML's heavy angle brackets, you might as well try JSON, which is lighter, more efficient, and more efficient to transmit.)
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 procedure call to the server, and get the result of the method execution returned by the server.
After XML-RPC, there is a more powerful SOAP for some more complex systems.
5. REST
Finally, let's look at REST, huh, this is a remote communication method (architecture) that I currently prefer.
REST is not a protocol, it is an architecture. If a Web Service can satisfy several conditions of REST, the system is usually called Restful.
The conditions mentioned here include:
1. C/S structure (this is a basic feature of Internet services)
2. Stateless (very familiar, huh)
3. Can be cached (remember the browser?)
4. Layered systems (remember the myriad of architectures?)
5. Unified interface (if this is possible, programmers are blessed)
6.code on demand (optional, actually an extensibility requirement)
After looking at these few features, what do you think of? You may burst out: HTTP. My answer: You got it!
HTTP is the core protocol of WWW. It unifies the simple resources distributed in all corners of the world, a unified address, a simple method, and a certain number of expressions. (You may have a vague description of these three points, please go ahead).
The three elements of REST are a unique resource identifier, a simple method (the method here is an abstract concept), and a certain expression. Look at the picture below: The Triangular Architecture of REST (from Restful User Experience )
REST is resource-centric, nouns are addresses of resources, verbs are some limited operations imposed on nouns, and expressions are abstractions of various resource forms.
Taking HTTP as an example, the noun is URI (Uniform Resource Identifier), the verb includes POST, GET, PUT, DELETE, etc. , html, image, pdf, etc.).
Six. The difference between RPC and REST
If you want to just remember one thing, then remember that RPC is verb-centric, REST is noun-centric, where verbs refer to methods and nouns refer to resources.
You will find that taking verbs as the center means that when you need to add new functions, you have to add more verbs. At this time, the server needs to implement the corresponding verbs (methods), and the client needs to know this new function. verb and make a call.
Taking the noun as the center, if I request hostname/friends/, no matter how the service corresponding to this URI changes, the client does not need to pay attention and update, and this change is also transparent to the client.
As for other differences, such as dependency on the implementation language, coupling, etc., these are derived from the fundamental difference mentioned above.
Let's go back to the 2 questions in the introduction part. When you use HTTP to surf every day, you are using REST to communicate with remote servers. When you use Gtalk to communicate with colleagues and friends, you are enjoying RPC. convenient.
Recommended reading Restful User Experience (this slide is the best explanation in my opinion) and ReST vs SOA(P) .
1. How to choose?
Usually if we are the client, we basically have no right to choose, and the service provider usually only has a service with one architecture. For example, facebook, Renren's open API (using REST).
But if we are lucky enough to design and implement our own Web Service, how should we choose?
According to the author's own experience and experience, it is recommended to use REST as much as possible if you can use REST, mainly based on the following considerations:
a. Extensibility
b. Loosely coupled (meaning, there is no need to force the client to update the corresponding code)
c. Client implementation language independent
d. Performance
e. Security (eg HTTPS)
Of course, the above points are not satisfied with RPC, but relatively speaking, REST is clearer and more concise, supplemented by JSON corresponding services, which will greatly improve performance and stability (simple usually means robust).
2. 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 open API of facebook/renren. It is a REST architecture, so even if facebook itself is developed in PHP, this does not prevent us from using python to develop, and there are more client API packages such as PHP, Java, .net, Perl. (Of course, Renren uses Developed in Java, we also use python).
So I was thinking, if facebook's architecture is not using REST, will there be such flexibility? If it is using RPC, our life may not be easy at present, and even our project cannot be approved!
In addition, because our front-end uses flash, and the python communication with the back-end uses djangoamf, the interesting thing is that if you know flash, you will know that AMF is a binary flash data exchange protocol, and it is based on RPC! Of course, as I said above, some architectures are not for us to choose, so the result of using RPC is that if we want to open the API of our game (if our game is popular enough, some friends want to develop peripheral applications based on our game) , which becomes very difficult. But at present, it is unlikely that we will open the API.
3. Conclusion
Whether based on verbs, nouns or messages, these are all for the purpose of providing us with a stable, reliable, secure, and easily extensible service. So, if you have the opportunity to provide open APIs for other clients (if your company is another facebook, twitter), you might as well consider developers based on your platform.
Article source: http://www.cnblogs.com/Tim-Yi/archive/2011/11/03/2234230.html