ПОЛУЧИТЬ и ОПУБЛИКОВАТЬ Лучшие практики

Пожалуйста, используйте POST для всего, что изменяет постоянное состояние в базе данных. Вы же не хотите, чтобы поисковые роботы посещали ваши ссылки на удаление!
Ознакомьтесь с Архитектурой Всемирной паутины, первым томом и URI, адресностью и использованием HTTP GET и POST W3C.

Редактировать: Иногда, хотя вам нужно использовать GET. Например, URL-адреса активации членства, которые отправляются по электронной почте, являются GET и должны каким-то образом изменить базу данных.

Вы никогда не должны изменять что-либо в своей базе данных (кроме информации о регистрации или других эфемерных данных) из запроса GET. Проблема в том, что существует различное программное обеспечение для веб-пауков, веб-ускорители, антивирусные программы и тому подобное, Которые будут выполнять запрос GET для каждого найденного URL-адреса; вы не хотели бы, чтобы они автоматически удаляли элементы, когда они это делают. GET также уязвим для подделки межсайтовых запросов; если злоумышленник заставляет одного из ваших пользователей нажать на ссылку, которая выполняет неправильное действие (например, создает tinyurl, который перенаправляет на URL-адрес для удаления), затем они могут обмануть пользователя, заставив его использовать свои разрешения для удаления чего-либо, не осознавая этого.

Да, вам понадобится форма, которую вы отправите, чтобы создать запрос на публикацию. Другой вариант - использовать JavaScript и XMLHttpRequest, но это не сработает для пользователей, у которых отключен JavaScript.

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

Вот хороший пример того, почему не следует использовать GET для изменения состояния сервера:

Http://www.infoworld.com/article/08/06/16/25FE-stupid-users-part-3-admins_5.html

Ключевая часть:

"Он вошел в административную область и перешел по ссылке "удалить" для каждой записи", - говорит администратор.

Если бы удаление было закодировано как СООБЩЕНИЕ, этого бы никогда не произошло. (ОТО нас лишили бы забавной истории сисадмина.)

Вы не хотите использовать Get из-за принципа REST, запрещающего Get изменять состояние системы. Если только вы не хотите, чтобы поисковые системы удаляли весь ваш контент.

Вам не понадобится форма для каждого элемента; вы можете использовать один метод=разместить форму по всему списку с типом ввода delete_{id}=отправить. Или, что более умно, . Имена разрешены на кнопках отправки.

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

Тот факт, что вы можете получить дополнительную, нежелательную информацию в отправке, смягчается средним случаем отправки страницы гораздо большего размера, чем необходимо, с помощью предлагаемого вами решения для каждой формы, когда вы просто просматриваете список. Вы всегда можете использовать javascript, чтобы заменить поведение простой старой html-формы более разумной версией для клиентов, поддерживающих javascript.

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

СООБЩЕНИЕ не является защитой от всего вредоносного поведения, как предполагают некоторые люди. Злоумышленники по-прежнему могут создавать ссылки (содержащие javascript для публикации) и вызывать те же проблемы с межсайтовыми сценариями, что и с GET. ()

Тем не менее, все остальные причины использования POST вместо GET применяются (поисковые роботы и тому подобное).

Как уже говорили другие, использовать GET для деструктивных операций, таких как удаление, действительно плохая идея, особенно на веб-сайтах, выходящих в Интернет (или корпорациях с мини-устройством Google), где поисковые роботы могут случайно удалить все ваши данные.

Если вы не хотите использовать форму, используйте запрос XMLHttpRequest для отправки сообщения на ваш сервер. Вы даже можете установить метод УДАЛЕНИЯ, если ваш сервер поддерживает это.

Если вы не можете использовать JavaScript и XHR (ваши пользователи живут в 1999 году), и вы не хотите использовать форму в своем списке, используйте ссылку на отдельную страницу, где вы можете показать форму и, возможно, сообщение "Вы уверены?".

Вероятно, лучше всего использовать комбинацию двух приведенных выше вариантов: отобразить ссылку на отдельную страницу с формой, но использовать JavaScript для перезаписи ссылки в виде вызова XHR. Таким образом, пользователи 1999 или 2009 годов могут получить оптимальный опыт.

Вы не должны использовать href для удаления элемента.

Я бы предложил сделать это по старинке и реализовать запись формы для каждой строки/элемента.

Например:

<tr><td>Item 1</td><td><form action=/delete method=post><input type=hidden name=id value=1><input type=submit value=Delete></form></tr>
<tr><td>Item 2</td><td><form action=/delete method=post><input type=hidden name=id value=2><input type=submit value=Delete></form></tr>
<tr><td>Item 5</td><td><form action=/delete method=post><input type=hidden name=id value=5><input type=submit value=Delete></form></tr>

Два других варианта: 1) использование одного с для каждого элемента 2) Ajax (но вам нужно будет хорошо владеть Ajax)

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

Все же лучше сделать это с помощью GET.

Если ваша проблема в том, что вам не нравится уродливый URL-адрес вашей ссылки, вы должны быть в состоянии исправить это с помощью mod_rewrite (если вы используете веб-сервер Apache).

Редактировать: Нет никаких причин использовать здесь СООБЩЕНИЕ. Нет. Причины.

Люди здесь пишут о безопасном и небезопасном, как будто выбор метода может каким-либо образом повлиять на безопасность. Конечно, вы должны аутентифицировать своего пользователя независимо от того, какой метод вы выберете. Если вы этого не сделаете, то ваш программное обеспечение уже сломано . Если вы используете javascript для эмуляции отправки формы, когда у вас нет формы, и она вам не нужна, вообще не нужен javascript, то ваше программное обеспечение уже сломано.

На самом деле, около 90 % веб-программного обеспечения сломано, потому что люди понятия не имеют о том, что они делают.

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