Я разрабатываю услугу REST WCF, и, как теоретически, я знаю, когда выбрать, для какой цели.
GET, чтобы получить ресурсPUT для обновленияPOST для вводаDELETE для удаленияНо каков недостаток, если мы не следуем приведенному выше правилу, предположим, что для вставки записи я использовал метод GET?
Поскольку метод HTTP GET указан как idempotent, запрос GET по спецификации может быть повторно представлен с предположением, что он ничего не изменит на сервере. Это не относится к HTTP POST, который по спецификации может изменять статус приложения, запущенного на сервере.
Таким образом, по спецификации, можно выполнить HTTP GET против страницы N количество раз, не беспокоясь о том, чтобы изменить свой статус.
Несоблюдение спецификации может иметь различные нежелательные результаты. Например, веб-сканеры следуют через GET-запрос для индексации сайта, но не POST. Если вы разрешили HTTP GET-запрос вносить изменения в базу данных, вы можете легко понять нежелательную импликацию, которую он может иметь.
Уважение спецификации соответствует соблюдению соглашения между вашим сервисом или веб-сайтом и множеством разных потребителей, которые могут быть обычными браузерами пользователей, а также другими службами, такими как веб-сканеры.
Вы можете создать сайт, который использует GET для вставки записи, но вы также должны ожидать, что все, что строится вокруг, чтобы потреблять ваш сайт, работает с предположением, что вы соблюдаете соглашение.
В качестве последнего примера веб-браузеры предупреждают пользователей, когда они пытаются обновить страницу, которая была достигнута запросом HTTP POST, предупреждающим, что некоторые данные могут быть повторно отправлены. Вы не получаете этот уровень защиты встроенных браузеров, если страница достигнута запросом HTTP GET.
Вы можете прочитать больше здесь: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Но каков недостаток, если мы не следуем приведенному выше правилу, предположим, что для вставки записи я использовал метод GET.
Поисковые системы получают доступ к вашим страницам с помощью запросов GET, поэтому, если вы это сделали, искатель Google может вставить записи, которые вам не нужны.
Часто люди будут использовать POST для любого запроса ajax, с фактическим действием в теле запроса. В этом нет ничего плохого, но здесь есть функция, поэтому вы можете ее использовать.
Я столкнулся с ситуацией, я должен был использовать PUT вместо GET. У меня был запрос на ввод разрешения третьим лицам (это был Google). Я закручиваю запрос Ajax GET для вызова разрешения на обновление для моего сервлета и от их вызова перешел на внешнюю службу. Для завершения запроса внешняя услуга заняла значительное количество времени. В то же время я видел дублирование одного и того же разрешения в моих журналах сервера. Это браузер, который продолжает называть сервер, говоря, что вы сделали? поскольку это GET, и браузер может вызывать сервер как можно больше раз. Браузер следил за стандартом, а мой код - нет. У меня была проблема не для стандартного.