почему нам нужно поставить и удалить в REST (полный) веб-сервис?

Question

Могу ли я позвонить в веб-сервис, как это а не использовать метод put and delete? это действительно веб-сервис REST?

....
$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')");
}
.....

Answer 1

Одна из основных идей REST - не предоставлять операционные методы как часть аргумента (в данном случае параметр 'operation').

Вместо этого каждый ресурс имеет свой уникальный URL-адрес и глаголы HTTP.(GET, POST, PUT или DELETE) используются на этих ресурсах.

Ваш подход не является RESTful.

Пример:

Удаление комментария с помощью API flickr:

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

Обратите внимание, как они используют параметр 'method', чтобы определить, какую операцию выполнить (как в вашем примере).

Реализация RESTful будет принимать что-то вроде:

DELETE /comment/28

В этом случае рекомендуется использовать POST для создания новых ресурсов, DELETE для их удаления, GET для получения существующих и PUT для обновления существующих.

Answer 2

Этот вид техники иногда называют " tunneling ", потому что он скрывает истинную операцию в теле общей операции POST.На мой взгляд, это своего рода хак и побеждает цель REST, но иногда это необходимо, если ваш веб-хост не позволяет использовать требуемые HTTP-глаголы.

Использование стандартных глаголов и понимание последствий , которые они делаюто вашем обслуживании является важным аспектом REST, который не следует упускать из виду.Например, вы должны иметь возможность многократно выполнять операцию DELETE на одном и том же ресурсе, и это должно привести к тому, что только первое DELETE будет иметь какой-либо эффект (идемпотент).При использовании GET следует предполагать, что на сервере не производится никаких изменений (безопасно).Но сокрытие операции внутри POST скрывает это.

Answer 3

Это на самом деле не RESTful сервис.Вам не нужно реализовывать все HTTP-глаголы, чтобы быть RESTful, но вы не должны использовать POST для УДАЛЕНИЯ данных.

Лично я бы реализовал DELETE для удаления элементов и использовал бы только POST для вставки данных.

Answer 4

Я собираюсь пойти против течения здесь и сказать, что прекрасно создавать сервисы RESTful без PUT и DELETE.Единственная ключевая вещь, о которой вам нужно знать, это то, от чего вы отказываетесь.

1) Посреднические компоненты (например, прокси, кэши, балансировщики нагрузки) не будут знать, создаете ли вы / обновляете илиудаляя ресурсы, они будут знать только, является ли операция безопасной (GET) или небезопасной (POST).Мой вопрос: знаете ли вы какие-либо промежуточные компоненты, которые используют эти знания?

2) Программист, который будет обращаться к вашему сервису, не сможет угадать, как УДАЛИТЬ ресурс, выПридется включить ссылку с отношением ссылки, в которой есть некоторая документация, объясняющая программисту, что для удаления ему потребуется POST к URI ссылки.Это немного больше работы для разработчика клиента, но, по крайней мере, вы недвусмысленно говорите о том, как это сделать.

И перед тем, как я забочусь о забвении, вот цитата Роя Филдинга, который говорит, что это тоже хорошо!

В любом случае, существует множество сервисов RESTful, которые ничего не делают, кроме GET и POST.Ключ в том, как эти методы используются, а не какие методы используются.Чтобы привести конкретный пример, то, что делает вики более или менее RESTful, почти всегда определяется тем, как она (ab) использует GET и сеансы - использует ли она PUT или POST для редактирования страниц, является сравнительным подсчетом.

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

Сказав все это, создание единого ресурса с именем webservice.php и передача параметра «операция» - неприятный запах дизайна с точки зрения REST.