why we need put and delete in REST(full) web service?

can i call a web service like this and not use put and delete method? is this a REST web service really?

....
$url = 'webservice.php';
$data = array(
    'username' => 'a',
    'password' => 'a',
    'param1'=> 'param1',
    'operation'=> 'delete',
    'output'=>'xml'
);
$client = curl_init($url);
curl_setopt($client, CURLOPT_POST,1);
....

...................

//webservice.php
$operation=$_开发者_运维问答POST['operation'];
$param1=$_POST['param1'];
if ($operation=='delete')
{
$r=mysql("delete from list where id='$param1'");
}
if ($operation=='insert')
{
$r=mysql("insert into  list values ('$param1')");
}
.....

---

One of the major ideas behind REST is to not give operational methods as part of the argument (in this case the 'operation' parameter).

Instead, each resource has its unique URL and the HTTP verbs (GET, POST, PUT or DELETE) are used on those resources.

Your approach is not RESTful.

Example:

Deleting a comment using the flickr API:

GET /services/rest/?method=flickr.photos.comments.deleteComment&comment_id=28

Note how they use a 'method' parameter to determine what operation to perform (like in your example).

The RESTful implementation would accept something like:

DELETE /comment/28

Best practise in this case would be to use POST for creating new resources, DELETE for removing them, GET for retrieving existing and PUT to update existing.

---

This kind of technique is sometimes called "tunneling" because it buries the true operation in the body of a generic POST operation. In my opinion it's kind of a hack and defeats the purpose of REST but sometimes it's necessary if your web host doesnt allow the required HTTP verbs.

Using standard verbs and understanding the implications they make about your service is an important aspect of REST that should not be overlooked. For example, you should be able to issue a DELETE operation repeatedly on the same resource and that should result in only the first DELETE having any effect (idempotent). With GET it should be assumed that no changes are being made on the server (safe). But hiding the operation inside of a POST obscures that.

---

This isn't really a RESTful service. You don't need to implement all HTTP verbs to be RESTful, but you shouldn't use POST to DELETE data.

Personally I'd implement DELETE for removing items and only use POST for inserting data.

---

I'm going to go against the tide here and say it is perfectly fine to create RESTful services without PUT and DELETE. The only key thing that you need to be aware of is what you are giving up in doing so.

1) Intermediary components(e.g. proxies, caches, load balancers) will not know whether you are creating/updating or deleting resources, they will only know if the operation is safe (GET) or unsafe (POST). My question is, do you know of any intermediary components that take advantage of this knowledge?

2) The programmer who is going to be accessing your service will not be able to guess how to DELETE a resource, you are going to have to include a link with a link relation that has some documentation that explains to the programmer that they will need to POST to the link's URI to do a delete. It's a bit more work for the client developer but at least you are being explicit about how to do it.

And before I get downvoted into oblivion, here is a quote from Roy Fielding who says it is ok too!

In any case, there are plenty of RESTful services that do nothing but GET and POST. The key is how those methods are used, not what methods are used. To give a specific example, what makes a wiki more or less RESTful is almost always determined by how it (ab)uses GET and sessions -- whether it uses PUT or POST for editing pages is sugar topping in comparison.

http://code.google.com/p/implementing-rest/wiki/FAQ

Having said all of this, creating a single resource called webservice.php and passing a "operation" parameter is a nasty design smell from the perspective of REST.