Initial Research on rest Architecture

An article in the IBM document AreaArticleRest Description: http://www.ibm.com/developerworks/cn/web/wa-ajaxarch/

What is rest? Find a simple and easy to understand: Building Web services the rest way.

Based on this article, 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, the URI defined in RFC is much more complicated, but here we can think of Uri as a personal ID card number (you cannot have two valid ID card numbers at the same time, A single number cannot correspond to two people at the same time ). The URL we talk about every day is a form of Uri (correct if there are any mistakes ).

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

The http://www.example.com/photo/logo points to the resource whose type is photo and whose name is logo in example.com (which can be considered a web application. We can access this URI in a browser and see An XHTML document, which uses To display the actual photo.

Http://www.example.com/photo/logo easily reminds you of URL rewriting. In fact, this address is likely to be processed as a http://www.example.com/photo.php inside the server? Name = logo. 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 DelphiProgramNow you only need to construct an HTTP request header containing accept: text/XML and then send the request to the http://www.example.com/photo/logo. 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, there are headers, put, delete, and other request methods in HTTP. In the rest architecture, different HTTP request methods are used to process CRUD (create, read, update, and delete) operations on resources:

• 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.

The server uses $ _ server ['HTTP _ Accept '], $ _ server ['request _ URI'], $ _ server ['request _ method'], and $ _ server ['query _ string'] These variables can solve the first three problems. The fourth problem can be implemented using the XMLHTTPRequest object of JavaScript.

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