Почему вы должны удалить с помощью HTTP POST или удалить, а не получить?

GET обычно свободен от побочных эффектов-другими словами, он не изменяет состояние. Это означает, что результаты могут быть кэшированы, закладки можно сделать безопасно и т. д.

с HTTP 1.1 RFC 2616

исполнители должны знать, что программа представляет пользователю в взаимодействия через Интернет, и следует быть осторожным, чтобы позволить пользователю быть в курсе любых действий, которые они могли бы возьмите, что может иметь неожиданное значимость для себя или других.

в частности, конвенция была установлено, что The GET и HEAD методы не должны иметь значение принятия мер другое чем возвращение. Эти методы должны считается "безопасным". Это позволяет пользователю агенты для представления других методов, такие как POST, PUT и DELETE, в специальный путь, так, что потребитель будет сделан осознавая тот факт, что запрашиваются небезопасные действия.

естественно, невозможно убедитесь, что сервер не создать побочные эффекты в результате выполнения запроса GET; фактически, некоторые динамические ресурсы считают, что особенность. Важное отличие вот что пользователь не запрашивал побочные эффекты, поэтому не может нести за них ответственность.

помимо проблем пуристов вокруг идемпотентности, есть практическая сторона: пауки/боты/искатели и т. д. будут следовать гиперссылкам. Если у вас есть действие" удалить " как гиперссылка, которая делает GET, то google может весело удалить все ваши данные. См."паук судьбы".

с сообщениями, это не риск.

пожалуйста, смотрите мой ответ здесь. Это в равной степени относится и к этому вопросу.

• Prefetch: многие веб-браузеры будут использовать предварительную выборку. Какие средства что он загрузит страницу перед вами нажмите на ссылку. Предвидя это вы нажмете на эту ссылку позже.
• боты: есть несколько ботов, которые сканируют и индексируют интернет для информация. Они будут только вопрос запросы. Вы не хотите удалить что-то из запроса GET для этого причина.
• кэширование: GET HTTP-запросы не должны изменять состояние, и они должны быть идемпотентными. Идемпотент означает, что выдача запроса один раз или его выдача многократно дает один и тот же результат. Т. е. побочных эффектов нет. Для по этой причине GET HTTP-запросы плотно привязан к кэшированию.
• стандарт HTTP говорит так: стандарт HTTP говорит, что каждый HTTP метод для. Несколько программ построены к используйте стандарт HTTP, и они предполагают что ты будешь использовать его таким, какой ты есть. положено. Так что вам придется неопределенное поведение из множества случайные программы, если вы не следуете.

другой пример..

http://example.com/admin/articles/delete/2

это удалит статью, если вы вошли в систему и имеете права доступа. Если ваш сайт принимает комментарии, например, и пользователь отправляет эту ссылку в виде изображения; например:

<img src="http://example.com/admin/articles/delete/2" alt="This will delete your article."/>

затем, когда вы сами, как пользователь admin, приходите просматривать комментарии на вашем сайте, браузер попытается получить это изображение, отправив запрос на этот URL. Но поскольку вы вошли в систему, пока браузер делает это, статья будет удалена.

Вы можете даже не заметить, не глядя на исходный код, так как большинство браузеров не показывает ничего, если он не может найти изображение.

надеюсь, что это имеет смысл.

об этой теме (Использование методов HTTP), я рекомендую прочитать это сообщение в блоге:http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/

Это на самом деле противоположная проблема: почему не использовать POST, когда данные не изменяются.

в дополнение к паукам и запросам, которые должны быть идемпотентными, также существует проблема безопасности с запросами get. Кто-то может легко отправить пользователям по электронной почте

<img src="http://yoursite/Delete/Me" />

в тексте и браузере будет счастливо идти и пытаться получить доступ к ресурсу. Использование POST не является лекарством для таких вещей (поскольку вы можете легко собрать сообщение формы в javascript), но это хорошее начало.

предположим, у нас есть приложение для интернет-банкинга, и мы посещаем страницу перевода. Вошедший в систему пользователь решает перевести $ 10 на другой счет.

нажатие на кнопку Отправить перенаправляет (как запрос GET) наhttps://my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j

но интернет-соединение медленное и / или сервер(ы) занят, поэтому после нажатия кнопки отправки загружается новая страница медленный.

пользователь расстраивается и начинает яростно нажимать F5 (страница обновления). Угадайте, что произойдет? Более чем одна передача произойдет, возможно, опустошение учетной записи пользователя.

теперь, если запрос сделан как сообщение (или что-то еще, кроме GET), первый F5 (страница обновления) пользователь сделает браузер мягко спросит: "Вы уверены, что хотите это сделать? Он может иметь побочные эффекты [ бла бла бла ] ... "

еще одна проблема с GET заключается в том, что команда переходит в адресную строку браузера. Поэтому, если вы обновите страницу, вы снова выполните команду, будь то" удалить последний материал"," отправить заказ " или аналогичный.

помимо всех превосходных причин, упомянутых здесь, GET-запросы могут регистрироваться сервером получателей, например, в access.log. Если вы отправляете конфиденциальные данные, такие как пароли в запросе, они будут регистрироваться как открытый текст.

даже если они хэшируются/солятся для безопасного хранения БД, нарушение (или кто-то, глядя через плечо ИТ-парня) может их выявить. Такие данные должны поступать в тело POST.