Зачем мне нужны PUT или DELETE Http-глаголы? - PullRequest
6 голосов
/ 22 марта 2010

После выхода MVC 2 я начал проверять и играть с новыми функциями, но я не мог понять, как используются глаголы PUT и DELETE.

Я искал об этом и прочитал несколько статей, но не смог получить.

Какова основная цель DELETE и PUT? Есть ли у них какие-либо преимущества перед использованием метода GET или POST (хотя я могу обработать все запросы с помощью GET и POST)?

Ответы [ 5 ]

13 голосов
/ 22 марта 2010
  • GET: Единственная функция - отправлять информацию обратно клиенту. Это должна быть повторяемая операция без побочных эффектов.

  • POST: он выполняет операции с побочными эффектами. не повторяется (если дважды выполнить POST, сервер будет работать дважды). После операции следует перенаправить на другую страницу, чтобы показать результаты с помощью GET.

  • УДАЛИТЬ: Его единственная функция - выполнять деструктивную операцию, не повторяемую (после удаления объекта удалить больше нечего).

  • PUT: его функция заключается в изменении одного объекта и обновлении его значениями, отправленными способом POST (как). Повторяется.

Вы можете подделать УДАЛИТЬ и PUT с POST (так как некоторые веб-браузеры не распознают УДАЛИТЬ и PUT).

Пожалуйста, используйте GET только для отображения информации, не для операций с побочными эффектами .

4 голосов
/ 22 марта 2010

В архитектуре RESTful DELETE предполагается использовать для запросов, которые будут удалять данные, а PUT предполагается использовать для запросов, которые вставляют данные.

2 голосов
/ 22 марта 2010

В основном он используется для лучшего разграничения действий / привилегий.

Идемпотентные методы и веб-приложения

Методы PUT и DELETE определены как идемпотентные, то есть несколько идентичных запросов должны иметьтот же эффект, что и один запрос.Методы GET, HEAD, OPTIONS и TRACE, прописанные как безопасные, также должны быть идемпотентными, поскольку HTTP является протоколом без сохранения состояния.В отличие от этого, метод POST не обязательно идемпотентен, и поэтому отправка идентичного запроса POST несколько раз может дополнительно повлиять на состояние или вызвать дополнительные побочные эффекты (например, финансовые транзакции).В некоторых случаях это может быть желательно, но в других случаях это может быть связано с несчастным случаем, например, когда пользователь не осознает, что его действие приведет к отправке другого запроса, или он не получил адекватную обратную связь о том, что его первый запрос былуспешный.Хотя веб-браузеры могут отображать диалоговые окна предупреждений для предупреждения пользователей в некоторых случаях, когда при перезагрузке страницы может повторно отправляться запрос POST, как правило, веб-приложение должно обрабатывать случаи, когда запрос POST не следует отправлять более одного раза.Обратите внимание: если протокол является идемпотентным, он не применяется протоколом или веб-сервером.Вполне возможно написать веб-приложение, в котором (например) вставка базы данных или другое неидемпотентное действие инициируется GET или другим запросом.Игнорирование этой рекомендации, однако, может привести к нежелательным последствиям, если пользовательский агент считает, что повторение одного и того же запроса безопасно, если это не так.

через википедиюhttp://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods

0 голосов
/ 22 марта 2010

Во-первых, вы должны проверить Очень хороший ответ BlaM на этот (обман?) Вопрос.

Очевидно, что вы можете технически создавать / обновлять / удалять ресурсы без использования принципов REST, но вы упускаете точку. Если вы до сих пор не понимаете концепцию REST, Запись в блоге Райана Томайко - хорошее место для начала.

0 голосов
/ 22 марта 2010

Первоначальной целью было редактирование веб-страниц с использованием этих глаголов ( больше в системе RESTful ).С тех пор они не поддерживаются расширением WebDAV .На практике PUT и DELETE никогда не используются (или очень редко - в пользовательских приложениях).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...