About rest.

Learning rest (reproduced: http://www.dualface.com/blog? P = 356)

Rest is a term proposed by Roy Fielding in his paper titled neural tural styles and the design of network-based software ubuntures.

Rest is the abbreviation of representational state transfer in English. It is translated into "representative State transmission" (see representational state transfer (rest) and data distribution in the SIP/IMS network).

-------------

The previous content is boring. Let me talk about my own understanding.

But what is rest? I don't understand this paper, but I found something easier to understand: Building Web services the rest way.

Based on thisArticle, I sorted out my own understanding of rest:

Rest is first of all an architectural style, not a standard. This is similar to Ajax, where both use existing mature technologies.

In the definition of rest, a Web application is alwaysUses a fixed URI to present (or expose) a resource to the external world..

Uri is the abbreviation of the English uniform resource identifier ".

"Generic resource identifier" refersA string that uniquely identifies a resource (XHTML file, image, CSS style sheet). Of course, RFC
The URI defined in
Imagine a person's ID card number (you cannot have two valid ID card numbers at the same time, and one number cannot correspond to two people at the same time ). The URL we talk about every day is
A form of Uri (for personal understanding, correct the error ).

After knowing what URI is, let's look at an actual example:

The http://www.example.com/photo/logo points to the example.com website (which can be considered a web
Application. We use a browser to access this URI. What we see may be an XHTML document, which uses
To display the actual photo.

Http://www.example.com/photo/logo makes it easy for you to think of URLs
Rewrite. In fact, this address is likely to be processed as a http://www.example.com/photo.php inside the server? Name = logo
Such an address. Photo. PHP is a dynamic script file on the server. The XHTML document is generated based on the name parameter and returned to the browser.

Now let's assume that we want to get the XML document of this photo. The XML document contains the photo file name, file size, shooting date, and other information. That is to say, we need to obtain"Data of different expressions of the same resource". For this requirement, we can easily use another URL address to reach: http://www.example.com/xml/logo.

However, this is against"URI uniquely identifies a resource". If we want to obtain multiple representations of the same resource, we need to use more URLs to specify multiple different Uris for a resource.

In rest, the same URI is used for both the XHTML document, XML document, and the photo file itself, that is, http://www.example.com/photo/logo.

What should I do? In Ruby on Rails, the HTTP request header information is distinguished from the data in which the client wants to obtain resources.

When we access a website using a browser, the browser constructs an HTTP request. This request contains a header containing the type of data that the request accepts. Generally, the accept value in the HTTP request header sent by the browser is */*, that is, accept any type of data returned by the server.

The smart guy should know it. If a specific accept parameter is specified, the server can determine the type of data returned by this parameter. Therefore, in an application that uses the rest architecture, you only need to use different HTTP request header information to obtain data of different expressions of the same resource.

If you consider adding web services to Web applications, the value of this technology will be reflected. For example, I wrote a Delphi
ProgramNow, you only need to construct an HTTP request header containing accept: text/XML, and then send the request
Http://www.example.com/photo/logo is enough. The returned result is an XML document instead of An XHTML document.

Because our HTTP request header information has different statuses, different data can be obtained, so it is called "concrete State transmission"

-------------

In addition to the above usage, rest has further extensions.

When processing requests from clients in a web application, we usually only consider the get and post HTTP request methods. In fact, HTTP also has
Head, put, delete, and other request methods. In the rest architecture, different HTTP request methods are used to process
Crud (create, read, update, and delete) operations:

• Post: Create
• Get: Read
• Put: Update
• Delete: Delete

After such expansion, we can perform crud operations on a resource through the same URI:

Http://www.example.com/photo/logo (read)
Remain as [get] http://www.example.com/photo/logo

Http://www.example.com/photo/logo/create (create)
Change to [Post] http://www.example.com/photo/logo

Http://www.example.com/photo/logo/update (updated)
Change to [put] http://www.example.com/photo/logo

Http://www.example.com/photo/logo/delete (Deleted)
Change to [delete] http://www.example.com/photo/logo

This further standardizes the use of resource IDs.

With the rest architecture, web applications can use consistent interfaces (URIs) to expose resources to the external world and provide resource operation services. This is very important for resource-centric Web applications. For example, photo sharing websites and usersCommunity.

-------------

Ruby on Rails 1.2 has good support for rest, but it still needs to solve many problems to apply rest in PHP:

• How to judge put and Delete request methods on the server side;
• How to obtain data transmitted in put and Delete request methods;
• How to obtain the value of accept in the HTTP request header;
• How to initiate put and delete requests on the browser side.

However, I carefully read the PHP documentation and I think the above issues can be solved.

Comprehensive server use
$ _ Server ['HTTP _ Accept '], $ _ server ['request _ URI'], and $ _ Server
The variables ['request _ method'] and $ _ server ['query _ string'] can solve the first three problems. The fourth problem can be used.
Javascript XMLHTTPRequest object.

However, I think the real value of rest lies in web services, rather than applications operated through browsers.