Go REST Learning

Transferred from Lio Yure to weblog

REST was a term put forward by Roy Fielding in his paper the architectural Styles and the design of network-based Software architectures.

REST is an abbreviation of the English representational state Transfer, which has Chinese translations for "representational status Transfer" (Reference: Representational states Transfer (REST) and data distribution in the SIP/IMS network 》）。

—————————————

The previous content is rather boring, I say my own understanding.

But what is REST in the end? I do not understand the paper, but find a more simple and understandable thing: "Building Web Services the REST Way."

Based on this article, I've sorted out my own understanding of REST:

REST is primarily a schema style, not a standard . This is similar to Ajax, both of which use existing mature technologies.

In the definition of REST, a WEB application always renders (or exposes) a resource to the outside world using a fixed URI .

URI is the abbreviation of English uniform Resource Identifier, Chinese Translation "Universal Resource marker".

A generic resource marker is a string that uniquely identifies a resource (XHTML file, picture, CSS style sheet) . Of course, the URI defined in the RFC is much more complicated, but we can imagine the URI as a person's ID number (you cannot have two valid ID numbers and one number cannot correspond to two people at the same time). And we are hanging on the mouth of the URL address is a form of representation of the URI (personal understanding, error, please correct).

After knowing what a URI is, let's look at a practical example:

Http://www.example.com/photo/logo point to the example.com Web site (which can be considered a Web application) in the type photo, the name of the logo resources. We use the browser to access this URI and see that it will probably be an XHTML document with to show the actual photos.

Http://www.example.com/photo/logo can easily make you think of URL rewriting. In fact, this address is likely to be handled internally within the server as a Http://www.example.com/photo.php?name=logo address. Photo.php is a dynamic script file on the server side that generates an XHTML document from the name parameter and returns it to the browser.

Now let's assume we're going to get the XML document for this photo. The XML document contains information such as the file name, file size, date taken, and so on. That is, we want to get "data in different representations of the same resource". For this request, we can easily use another URL address to reach: Http://www.example.com/xml/logo.

However, this violates the "URI uniquely identifies a resource" definition. If we want to get multiple representations of the same resource, we need to use more URLs to give a resource a number of different URIs.

In REST, either the XHTML document that gets the photo or the XML document, or the photo file itself, uses the same URI, which is Http://www.example.com/photo/logo.

So how did this happen? Ruby on Rails distinguishes the HTTP Request Header information from the data that the client is looking for in the form of a resource.

When we use a browser to access a URL, the browser constructs an HTTP request. This request has a header message that includes what type of data this request accepts. Typically, in the HTTP request header sent by the browser, the value of the Accept is */*, which means that any type of data returned by the server is accepted.

See here, the smart guy should know. As long as we specify a specific Accept parameter, the server can determine what type of data to return by judging the parameter. So in a REST architecture application, to get data in different representations of the same resource, you just need to use different HTTP request header information.

If you consider adding Web Services to your Web application, the value of this technology is evident. For example, I wrote a Delphi program, now only need to construct a containing Accept:text/xml HTTP request headers, and then send the request to Http://www.example.com/photo/logo on it. The result returned is an XML document, not an XHTML document.

Because our HTTP request header information has a different state so that different data can be obtained, it is called "representational state transmission".

—————————————

In addition to the above usage, REST has a further extension.

When we process requests from clients in a WEB application, we usually consider only the two HTTP request methods of Get and POST. In fact, HTTP also has the head, put, DELETE and other request methods. In the REST architecture, different HTTP request methods are used to handle CRUD (create, read, update, DELETE) operations on resources: POST: Create get: Read put: Update Delete: delete

After such an extension, our CRUD operations on a resource can be done with the same URI:

Http://www.example.com/photo/logo (Read)
Still 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 (update)
Change to [put] Http://www.example.com/photo/logo

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

Thus further standardizing the use of resource identification.

With the REST architecture, WEB applications can expose resources to the outside world with consistent interfaces (URIs) and provide operational services to resources. This is important for resource-centric WEB applications. such as photo-sharing sites, user communities, and so on.

—————————————

Ruby on Rails 1.2 has good support for rest, but there are a number of questions to be applied to applying rest in PHP: How to judge the put and delete request methods on the server side, how to get the data that is passed in the in-use, delete request method, and how to get H The value of the Accept parameter in the TTP request header information, and how to initiate the put and DELETE requests on the browser side.

However, I read the PHP document carefully, I think the above several problems can be solved.

Service-side integrated use of $_server[' http_accept '], $_server[' Request_uri ', $_server[' Request_method ', $_server[' query_string '] These variables should be able to handle the previous three questions. The fourth problem can be implemented using JavaScript's XMLHttpRequest object.

But I think the real value of REST is Web Services, not applications that are manipulated through browsers.