Three common types of Web services architectures

Transfer from http://www.cnblogs.com/bvbook/archive/2008/12/24/1360942.html

Competing service architectures

The competing architectures

We've given the two main issues of how different Web services can be done, and now we're going to classify different styles of Web services accordingly. According to my research, there are three main types of Web services architectures: RESTful architecture, RPC architecture, and REST-RPC hybrid architecture. They are described in turn below.

RESTful, resource-oriented architecture

RESTful, resource-oriented architectures

The theme of this book is a restful Web services architecture-they can score very high scores according to the criteria in the Dr. Roy Fielding dissertation. Now, while many architectures are technically restful (note 3), I want to focus on the architecture that best suits Web services, so when I talk about restful Web services, I'm referring to services that have Web features- Call them resource-oriented (resource-oriented). The basic concept of resource-oriented rest is introduced in the 3rd chapter through a real Web service--amazon S3 (simple Storage Service), and then in chapter 4th, we introduce you to the signature features of rest, and define a schema that is well suited to restful Web services-resource-oriented architecture (resource-oriented Architecture).

The restful architecture means that the method information is in the HTTP method, and the resource-oriented architecture (ROA) means that the scope information (scoping information) is in the URI-- The combination of the two is very powerful. A resource-oriented restful Web service that, through the first line of HTTP requests (such as "Get/reports/open-bugs http/1.1"), has a basic understanding of what the client is doing, and the remainder of the HTTP request is just the specifics. In fact, many HTTP requests are as long as the first line. If the HTTP method is not the same as the method information, then the service is not restful, and if the scope information is not placed in the URI, then the service is not resource-oriented. Although not only these two requirements, but they are very good experience.

L provide services for the Atom Release Protocol (Http://www.ietf.org/html.char ters/atompub-charter.html) and its variants, such as Gdata (http/ code.google.com/apis/gdata/)

L Amazon S3 (Simple Storage Service) (http://aws.amazon.com/s3)

L Yahoo! Most of the Web services provided (http://developer.yahoo.com/)

L Many other read-only Web services that are not soap-based

L Static website

L Many Web applications (especially read-only like search engines)

When it comes to non-restful architectures or non-resource-oriented architectures, I have a certain purpose. This chapter will take a holistic look at RESTful Web services under the background of the programmable web. In the 2nd chapter, we will mention some real Web services and point out that whether a service is exactly what I recommend, you can access it with the same client tools. In the 10th chapter, the idea of "how to design programmable Web" is a distant topic.

RPC-style architecture

Rpc-style architectures

RPC Web Services (Rpc-style Web service) typically receives a data-filled envelope (envelope) from the client and then sends back an envelope that is also full of data. The RPC-style architecture means that both the method information and the scope information are in the envelope (envelope) or header (headers). The type of envelope used does not affect the classification here, but HTTP is a common envelope format (after all, HTTP is the Web service). Another common envelope format is soap (placing the SOAP envelope in an HTTP envelope and transmitting the SOAP document on HTTP). Each RPC service uses its own vocabulary, just like a computer program (each time you write a program, the name of the function you define is different). Instead, restful Web services share a standard set of words, the HTTP method. Every object in a restful service has a unified basic interface.

Xml-rpc is an example of the most typical RPC architecture. Although XML-RPC is primarily a legacy protocol (Legacy Protocol), it is relatively simple and easy to explain, so I'm ready to start with it. The Ruby client shown in example 1-11 is used to access a XML-RPC service that queries a product that has a unified product code (UNIVERSAL).

Example 1-11: an example of accessing the XML-RPC service: Search for products based on UPC

#!/usr/bin/ruby-w

# XMLRPC-UPC.RB

Require ' xmlrpc/client '

def find_product (UPC)

Server = xmlrpc::client.new2 (' http://www.upcdatabase.com/rpc ')

begin

response = server.call (' LOOKUPUPC ', UPC)

Rescue xmlrpc::faultexception = e

puts " Error:"

puts E.faultcode

puts e.faultstring

End

End

Puts Find_product ("001441000055") [' description ']

# "Trader Joe ' s Thai rice noodles"

XML-RPC service just like C, you can call a function (LOOKUPUPC) with a parameter ("001441000055")and get the return value. The method information (function name) and scope information (parameters) are placed in the XML document (as shown in example 1-12).

Example 1-12: An XML document that describes the XML-RPC request

<?xml version= "1.0"?>

<methodCall>

<methodName>lookupUPC</methodName>

<params>

<param><value><string>001441000055</string></value></param>

</params>

</methodCall>

This XML document is passed to the server in an envelope. The envelope here (envelope) is an HTTP request consisting of an HTTP method, URI, header, and entity body, where the entity body is the XML document above (as shown in example 1-13).

Example 1-13: An HTTP envelope that contains an XML document that describes the XML-RPC request

Post/rpc http/1.1

Host: www.upcdatabase.com

User-agent:xmlrpc::client (Ruby 1.8.4)

Content-type:text/xml; Charset=utf-8

content-length:158

Connection:keep-alive

<?xml version= "1.0"?>

<methodCall>

<methodName>lookupUPC</methodName>

...

</methodCall>

The XML document in the HTTP envelope above will vary depending on the method you call, but the HTTP envelope format is always the same. Whatever your request for this UPC query service, the URI is always http://www. Upcdatabase.com/rpc, the HTTP method is always post. Simply put, the XML-RPC service does not employ many of the features of HTTP; it exposes only one URI (called an "endpoint"), and the URI supports only one HTTP method--post method.

RESTful services expose different URIs for different scope information, whereas RPC services typically expose a URI for each "document processor" (used to open the envelope and convert the envelope to a software directive). Let's make a comparison, assuming that the UPC query service is designed as a restful architecture, then its client-side code will look like example 1-14.

Example 1-14: Hypothetical sample code: A Rest-UPC query Service

Require ' Open-uri '

Upc_data = open (' http://www.upcdatabase.com/upc/00598491 '). Read ()

...

here, the method information is contained in the HTTP method (the default HTTP method is get, which corresponds to LOOKUPUPC in example 1-13 ), and scope information is included in the URI. This hypothetical service exposes more than one URI, and each UPC code has a URI corresponding to it. Unlike example 1-13, where the HTTP envelope is empty-it is an HTTP GET request with no entity principal.

An example of another RPC service can be found in the example 1-8:google SOAP API is an RPC service that uses SOAP as an envelope format.

More or only HTTP POST service, mostly RPC-type services. While this is not absolute, it can at least indicate that the service does not use the HTTP method for expressing method information. If a restful service is overloaded with HTTP POST, it can easily evolve into a rest-rpc hybrid architecture.

Here are some examples of well-known RPC Web services:

L All services using XML-RPC

L almost all soap services (this is controversial, this is discussed in the section "Programmable Web-related technologies" later in this chapter)

L Few Web applications (usually not designed)

REST-RPC Hybrid Architecture

REST-RPC Hybrid Architectures

This term was created by me to describe a Web service between a restful architecture and a purely RPC-like architecture. These services are often created by those who know more about real-world Web applications, but who are not fine with rest theory.

Let's revisit the URI used when invoking the Flickr Web service:http://www.flickr.com/services/rest?api_key=xxx&method= Flickr.photos.search&tags=penguin. Although the word "rest" is included in the URI, it is clearly an RPC service with an HTTP envelope. On the other hand, its scope information ("Photos with ' penguin ' tag") is placed in a URI--from this point of view, it is a bit like restful resource-oriented services, but its method information ("Search photos") is also placed in the URI, and as previously said, for restful services, The method information should be placed in the HTTP method, and the remainder is all scoped information. It seems that the service only uses HTTP as an envelope format, and then puts the method information and scope information to its own volition--this is an RPC service, the authentication is complete!

However, let's look at example 1-15.

Example 1-15: an example of sending an HTTP request to the Flickr Web service

GET Services/rest?api_key=xxx&method=flickr.photos.search&tags=penguin http/1.1

Host:www.flickr.com

This is the HTTP request made when the client invokes the Flickr Web service. Here, it seems, the method information is in the HTTP method. The intent of this request is to get (get) data. What data do you get? A search results List of "photos with a ' penguin ' tag". The data that looked like method information ("Search photos") now appears to be scope information ("Photos/tag/penguin"). The service, which was identified as RPC, is now in restful style.

This is an illusion. This illusion occurs when an RPC service uses normal old-fashioned http (Plain-HTTP) as the envelope format, and the method information and scope information are exactly in the URI path of the HTTP request. If the HTTP method is get, and the intent of requesting the service is also "get" information, it is difficult to tell whether the method information is in the HTTP method or in the URI. So you'll consider an HTTP request for an RPC service as a RESTful Web service HTTP request. This HTTP request may contain "Method=flickr". Photos.search ", this information is mistaken for scope information (just as" photos/"and" search/"are scope information). These RPC services, inadvertently and more or less with the characteristics of a restful web service. They only use HTTP as an envelope format, but they may be using HTTP envelopes in a way that is similar to the rest-service approach.

Many read-only Web services, although they may have been designed in RPC style at first, can be said to be completely restful and resource-oriented! However, if the service allows the client to modify the data, there is a case where the HTTP method used by the client is inconsistent with the actual method information-so that it does not have the characteristics of a restful service. Like this service, I call it the REST-RPC hybrid service.

Let me give you an example. Even if the client's intention is to modify the data, the Flickr Web API still lets the client use HTTP GET. If you want to delete a photo, you need to make a GET request to a URI that contains "method=flickr.photos.delete", although the intent of your request is not to get (get) data, as I said in chapter 5th. The Flickr Web API is a REST-RPC hybrid architecture: When a client obtains data through a GET method, it is restful, and when the client modifies the data through the Get method, it is RPC-style.

Some well-known REST-RPC hybrid Web services include:

L del.icio.us API

L Flickr Web API

• Many of the Web services that are said to be restful architectures

L Most Web applications

From the point of view of design, I think no one will intentionally design the service as a REST-RPC hybrid architecture. Because of the way HTTP works, any RPC-style service that uses normal HTTP and exposes multiple URIs often ends up as a restful or hybrid architecture. Many programmers design Web services in the way they design Web applications and eventually form a hybrid architecture service.

The existence of mixed architectures has caused a lot of confusion. People engaged in Web application design tend to design REST-RPC hybrid architectures, and they often claim that the hybrid architecture is a restful architecture-they are still designing Web services in a way that designs human web. There is already a lot of effort spent on resolving restful architectures and other architectures. I call "other architectures" the REST-RPC hybrid architecture, which is one of many new words, and I think the new word is the most accurate and effective way to look at these common and confusing services. If you know their other names ("Http+pox" is the most popular when writing a book), you might as well read on, and I'll explain these other terms in my own language later.

Three common types of Web services architectures