Rest introduction and the application of rest in PHP

When HTTP is invented, rest is already there. Unfortunately, over the years, the Web development model has increasingly deviated from the nature of HTTP, trifles the pursuit of RPC and other things. At this point rest back into the eyes of people, no doubt let everyone begin to reflect on the past detours.

This article does not want to introduce rest from scratch, just to illustrate some of the issues that need to be noted:

Let's take a look at some of the people's doubts about rest:

What does rest look like?

The most general rest example looks like this:

1	POST   /articles     创建

2	DELETE/articles/123 删除

3	PUT    /articles/123 更新或创建

4	GET    /articles/123 查看

By the way, a few points of knowledge:

The get operation is secure. Security means that the state of a resource does not change regardless of how many times it is done. For example, I use get browse articles, no matter how many times, the article is still there, no change. Of course, you may say that every time you browse the article, the number of views on the article add one, this does not change the state of the resources? This is not contradictory, because this change is not caused by a get operation, but rather by the user's own set of service-side logic.

The put,delete operation is idempotent. Idempotent means that the results are the same regardless of the number of operations performed. For example, I use put to modify an article, and then do the same operation, after each operation the result is not different, delete is the same. By the way, because the get operation is safe, it is naturally idempotent.

The post operation is neither secure nor idempotent, such as a common post repeat loading problem: when we make the same post request several times, the result is that we have created a number of resources.

The significance of security and power is that when the operation does not reach the desired target, we can retry without any side effects on the resource. In this sense, the post operation is often harmful, but many times we still have to use it.

Another thing to note is that the create operation can use post, or put, except that the post is acting on a collection resource (/articles), and the put operation is on a specific resource (/articles/123), and then, in a more popular sense, If the URL can be determined on the client, then use put, if it is determined on the server, then use post, for example, many resources use the database self-increment primary key as identity information, and the identity information of the created resource is what can only be provided by the server, this time must use post.

What if the browser does not support the Put/delete method?

Most browsers only support the Get/post method, which makes it impossible for us to implement rest perfectly. In this case, there are a few workarounds, one is to add a _method name to the form of a hidden field, to represent the real method, and the other is to use the X-http-method-override header information to overload the post.

Do you have enough HTTP methods?

From the above example, we can see that by using the existing HTTP method: Post,delete,put,get can complete the deletion of resources and search, but in the actual situation, we need to do the operation is often not limited to simple additions and deletions to the operation, for example, we want to put an article "pinned ", but there is no method in the HTTP method that corresponds to the" sticky "operation, what should I do? Rest's solution to a similar problem is: Create a new resource! In the example above, we can do this:

1	PUT /toparticles/123

By creating a new resource (toparticles), we can use the simple HTTP method to take all of the actions.

Does rest oppose the use of the session?

Keep in mind that rest refuses to session! This is because rest emphasizes statelessness. This state refers to the state of the application, which can also be called session state. Once this is maintained on the server side, the scalability of the architecture will be greatly compromised. In rest, any similar state should itself be a separate resource.

are cookies harmful to rest?

In Split, if the cookie is stored in the application state, there is no problem. This is because the application state belongs to the client. But it's not right to use cookies to keep things like Phpsessionid, because such data is not part of the client state, it's just an excuse to use the session.

Let's look at the status of rest in PHP:

There are few rest implementations in PHP, some of which are cakephp and Zend, and the following are their implementations:

Cakephp:

To set the route:

1	Router::parseExtensions(‘xml‘);

2	Router::mapResources(‘articles‘);

Write the controller:

1	classArticlesController extendsAppController {

2	var$components= array(‘RequestHandler‘);

3	functionview($id= null) {

4	$article= $this->Article->findById($id);

5	$this->set(compact(‘article‘));

6

}

7

// ...

8

}

View:

1	<articles>

2	<?php echo$xml->serialize($article); ?>

3	</articles>

This is almost the case, and the corresponding, other functions can be implemented, so the following rest operations are possible:

1	POST   /articles

2	DELETE/articles/123.xml

3	PUT    /articles/123.xml

4	GET    /articles/123.xml

In general, CakePHP's rest implementations are basically implemented in the rails style, largely passable.

Zendframework:

Zendframework uses the Zend_rest component to implement REST functionality:

Service side:

1	require_once‘Zend/Rest/Server.php‘;

2	functionsayHello($who, $when)

3

{

4	return"Hello $who, Good $when";

5

}

6	$server= newZend_Rest_Server();

7	$server->addFunction(‘sayHello‘);

8	$server->handle();

Client:

1	require_once‘Zend/Rest/Client.php‘;

2	$client= newZend_Rest_Client(‘http://path/to/server/script‘);

3	$client->sayHello(‘Davey‘, ‘Day‘);

4

5	echo$client->get();

At this point, we look at the log of the Web server and find a record of the following:

1	GET /path/to/servier/script?method=sayHello&arg0=Davey&arg1=Day&rest=1 HTTP/1.1

We found that the actual operation method is specified by the Method=sayhello in the URL, while the HTTP native method (Get/post, etc.) becomes the device, which is the typical RPC style, if you compare zend_rest and ZEND_XMLRPC documents, It is obvious that they are simply a thing, so zend_rest is a rest pseudo-implementation.

This basic REST design principle establishes a one-to mapping between creating, reading, updating, and deleting (create, read, update, and Delete,crud) operations and HTTP methods. Based on this mapping:
1) to create a resource on the server, you should use the POST method.
2) to retrieve a resource, you should use the GET method.
3) To change the status of a resource or update it, you should use the PUT method.
4) To delete a resource, you should use the Delete method.

Rest introduction and the application of rest in PHP