Rest-style URLs

I used to think/nowamagic/article/article_id such an address is very beautiful, but it is just appearance, understand in depth, found that there must be a client Ajax engine and server side of the service to cooperate, To implement a restful application, here's my experiment.

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:

1	<matchid="995">

2	<scoreteam="bluebaggers">150</score>

3	<scoreteam="redlegs">60</score>

4

</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

1	<matchid="995">

2	<scoreteam="bluebaggers">150</score>

3	<scoreteam="redlegs">60</score>

4

</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:

• URL represents a resource
• The HTTP method represents the operation
• Get is used only to request an operation, and a 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.
• 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.

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

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

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

Rest-style URLs