Rest-style Application implementation

Don't laugh at me old-fashioned, because I've only recently heard of restful style, I used to think/category/product/pid

This kind of address is very beautiful, but it is just appearance, understand in depth, found that there must be a client's Ajax engine and server side of the service to achieve a restful application, the following is my experiment.

problem.

What services are available to the outside. Server-side services may be requested by a large number of browsers, may also be called by third-party applications, so the overall need to consider the external "application Interface" (API), as far as possible to maintain the stability of the interface. Rest is a style, and it forms its own rules, and to build such an application, you should follow the principles of rest as much as possible.

Taking a football service as an example, a large number of viewers will ask for a record of the game, upload a new record, update the record, correct an existing match or delete a match, etc. As described in this way, we need to provide many different services, and will eventually fall into the maintenance of consistency of work. So what should be done, consider how the client might request it:

Get mode request a new tournament service:

Http://example.com/newMatch?id=995&bluebaggers=150&redlegs=60

Post or put to request a new tournament service:

Http://example.com/newMatch

The additional XML is:

<match id= "995" >

<score team= "Bluebaggers" >150</score>

<score team= "Redlegs" >60</score>

</match>

CGI-style post or put request:

Http://example.com/newMatch

Request Body:

Id=995&bluebaggers=150&redlegs=60

or a GET request for a maintenance service:

Http://example.com/matchMaintenance/command=newMatch&id=995&bluebaggers=150&redlegs=60

or POST request

Http://example.com/matchMaintenance/command=newMatch

<match id= "995" ><score team= "bluebaggers" >150</score><score team= "Redlegs" >60</score ></match>

And so on, there can be many such functions. Some people think this is not a problem, for more and more requests, we just set up the service, and then give the corresponding instructions. However, he still has shortcomings.

Maybe we'll assume that the access is just from the script, so this might be a little simpler. In fact, there are a number of factors that can be involved, such as a Web browser (there are issues with the retreat and Refresh buttons), a Web server (which may have caching and compilation problems), network routing and caching problems, harassment of crawlers, and crawling of site content by some personal sites. If we consider these different requests, our program can behave more robustly.

Ideally, a service should have the ability to explain itself. If a service is built on a conventional set of conditions, then it is easy for people to adapt and develop in the future.

Rest is about these factors, and you can use restful APIs to implement the services above.

Introduction to RESTful principles

The main principles of rest are:

represents a resource with a URL. resources, like business entities, are part of what we want to render as API entities. Usually a noun, each resource is represented by a unique URL.

The HTTP method represents the operation. rest takes full advantage of the HTTP approach, especially get, POST, put, and delete. Note that the XMLHttpRequest object implements all the methods, the specific can be see the world's HTTP 1.1 specification.

In other words, any request from the client includes a URL and an HTTP method. Back in the example above, the game is obviously an entity, so a request for a particular match is expressed as:

http://example.com/matches/995

This approach is clear, and may be different from the exact naming method, but as long as you follow this form, we can quickly get, DELETE, update, and create new operations.

the principle of restful:

1. URL indicates resource

2. HTTP method indicates operation

3, get is only used to request the operation, get operation should never modify the state of the server. But this also need to be specific analysis, such as a page of the counter, each time the visit did cause the server data changes, but in business, this is not a very important change, so you can still receive the use of get to modify the data.

One case, using get method to modify the case of loss of data

Witness the the the debacle caused by the Google Accelerator interacting with non-restful services in mid-2005. The accelerator jumps ahead of the user and prefetches each link in case they should click on it (a non-ajaxian example of Predictive Fetch). The problem came when users logged into Non-restful applications Likebackpack. Because Backpack deletes items using get calls, the accelerator-in its eagerness to activate each GET query-ended up D Eleting personal data. This could happen with regular search engine crawlers too, though the issue doesn ' t tend to come up because they don ' t hav e access to personal accounts.

4, the service should be stateless

In a stateful session, the server can record the previous information. In restful style, you should not let the server record the state, only in this way the server is extensible. Of course, we can use cookies on the client and only when the client sends the request to the server.

5, the service should be "idempotent"

Idempotent means that you can send a message to a service, and then you can send the same message to the service again effortlessly. For example, sending a "delete No. 995 Game" message can be sent once or 10 times in a row, and the final result will be consistent. Of course, restful get requests are usually idempotent, because the state of the server is basically not changed. Note : A POST request cannot be defined as idempotent, especially when a new resource is created, one request creates a resource, and multiple requests create more than one resource.

6. Hug Hyperlink

7, the service should be self-explanatory

For example, http://example.com/match/995 requested a specific match, but Http://example.com/match did not request any entities, so some introductory information should be returned.

8, service constraint data format. Data must conform to the required format

In PHP programs, you want to implement this restful URL, just rely on the program is not possible, also need to configure rewrite rules on the server side, for example, for a RESTful resource request:

http://www.api.com/product/113

The generic implementation of the script is

http://www.api.com/product.php?id=113

This is based on QueryString, can also be a unified index.php portal, and then by the way of processing URIs, such as:

http://www.api.com/index.php/product/113

Such URLs can be rewrite to achieve restful style. In a word, rest is a design style that provides a principle for us to organize our own application design, while using these principles to bring about the traversal, can be flexibly handled according to the actual situation.

Resources:

1. RESTful Service

2. RPC Service

3. HTTP Methods

4. Verbs Can also be nouns