Выйти: GET или POST?
Этот вопрос не о том, когда вообще следует использовать GET или POST, , а о том, который является рекомендуемым для обработки выхода из веб-приложения. Я нашел много информации о различиях между GET и POST в общем смысле, но я не нашел определенного ответа для этого конкретного сценария.
Как прагматик, я склонен использовать GET, потому что его реализация намного проще, чем POST; просто оставьте простую ссылку, и все готово. Это, кажется, имеет место с подавляющим большинством веб-сайтов, о которых я могу думать, по крайней мере, из головы. Даже Stack Overflow обрабатывает выход с помощью GET.
Что меня беспокоит, так это (хотя и старый) аргумент, что некоторые веб-ускорители / прокси-серверы предварительно кэшируют страницы, просматривая и извлекая каждую ссылку, найденную на странице, поэтому пользователь получает более быстрый ответ, когда нажимает на них. Я не уверен, что это все еще применимо, но если бы это было так, то теоретически пользователь с одним из этих ускорителей будет выгнан из приложения, как только он войдет в систему, потому что ее ускоритель найдет и получит выход из системы. ссылку, даже если она никогда не нажимала на нее.
Все, что я до сих пор читал, предполагает, что POST следует использовать для «деструктивных действий», тогда как действия, которые не изменяют внутреннее состояние запросов, подобных приложению, и тому подобное - должен обрабатываться с помощью GET . Исходя из этого, реальный вопрос здесь:
Считается ли выход из приложения разрушительным действием или он изменяет внутреннее состояние приложения?
7 ответов
Чтобы быть правильным, GET / POST (или другие глаголы) - это действия на некотором ресурсе (адресуются по URL-адресу), поэтому его обычно о состоянии ресурса, а не о состоянии приложения как такового. Итак, в истинном настроении у вас должен быть URL, такой как [имя хоста] \ [имя пользователя] \ сессия , тогда «УДАЛИТЬ» будет правильным глаголом для действия выхода.
Использование [имя хоста] \ bla bla \ logout в качестве URL-адреса не совсем как REST full way (IMO), так зачем спорить о правильном использовании GET / POST на нем?
Конечно , Я также использую GET для выхода из системы в своих приложениях: -)
Одним из способов злоупотребления GET здесь является то, что человек (возможно, конкурент :) разместил тег изображения с помощью src = "<ссылка для выхода из системы>" В ЛЮБОМ месте в Интернете, и если пользователь вашего сайта наткнется на эту страницу, он выйдет из системы по незнанию.
Интересен сценарий предварительного кэширования. Но я предполагаю, что если много сайтов, включая ТАК, не беспокойтесь об этом, то, возможно, и вам не стоит.
Или, возможно, ссылку можно было бы реализовать в javascript?
Изменить: Насколько я понимаю, технически GET должен быть для запросов только для чтения, которые не меняют состояние приложения. POST должен быть для запросов на запись / редактирование, которые изменяют состояние. Однако другие проблемы приложений могут предпочесть GET вместо POST для некоторых запросов на изменение состояния, и я не думаю, что с этим есть какие-либо проблемы.
Выход из системы ничего не делает с самим приложением. Он изменяет состояние пользователя по отношению к приложению. В данном случае, похоже, ваш вопрос основан на том, как пользователь должен инициировать команду для начала этого действия. Поскольку это не "разрушительное действие", то есть сеанс покидается или уничтожается, но ни ваше приложение, ни ваши данные не изменяются, нет ничего неосуществимого в том, чтобы позволить обоим методам инициировать процедуру выхода из системы. Post должен использоваться для любых действий, инициированных пользователем (например, пользователь нажимает кнопку "Log out"), в то время как get может быть зарезервирован для выхода из системы, инициированного приложением (например, исключение, обнаруживающее потенциальное вторжение пользователя, принудительно перенаправляет на страницу входа в систему с помощью logout GET).
В REST не должно быть сессий, поэтому уничтожать нечего. Клиент REST аутентифицируется по каждому запросу. Зашли или вышли, это просто иллюзия.
На самом деле вы спрашиваете, должен ли браузер продолжать отправлять аутентификационную информацию при каждом запросе.
Возможно, если ваше приложение создает иллюзию входа в систему, вы должны иметь возможность «выйти из системы» с помощью javascript. Поездка туда и обратно не требуется.
Филдинговая диссертация - Раздел 5.1.3
каждый запрос от клиента к серверу должен содержать всю информацию необходимо понять запрос, и не может воспользоваться никакими сохраненный контекст на сервере. Сессия состояние поэтому остается полностью на клиент
Что ж, если вы позволите своему веб-приложению прервать сеанс с помощью сценария выхода из системы, вам обычно не понадобится ни то, ни другое. Обычно существует переменная сеанса, уникальная для сеанса, который вы хотите прервать.
Я не понимаю, как выход из системы (снижение прав пользователей) является деструктивным действием. Это потому, что действие «выйти из системы» должно быть доступно только пользователям, которые уже вошли в систему, иначе оно устарело бы.
Случайно сгенерированная строка, содержащаяся в файлах cookie вашего браузера, представляет собой ваш пользовательский сеанс. Есть масса способов уничтожить его, поэтому выход из системы - это просто услуга для вашего посетителя.