Выйти: ПОЛУЧИТЬ или ПОСТИТЬ?

Question

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

Как прагматик, я склонен использовать GET, потому что реализовать его намного проще, чем POST; просто оставьте простую ссылку, и все готово. Это, кажется, имеет место с подавляющим большинством веб-сайтов, о которых я могу думать, по крайней мере, из головы. Even Stack Overflow обрабатывает выход с помощью GET.

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

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

Считается ли выход из приложения разрушительным действием или он изменяет внутреннее состояние приложения?

Answer 1

Использование POST.

В 2010 году использование GET, вероятно, было приемлемым ответом.Но сегодня (в 2013 году) браузеры будут предварительно выбирать страницы, которые, по их мнению, будут посещаться вами в следующий раз.

Вот один из разработчиков StackOverflow, который обсуждает эту проблему в твиттере:

Я хотел бы поблагодарить мой банк за выход из GET-запроса и команду Chrome за удобную предварительную выборку URL-адресов. Ник Крейвер ( @ Nick_Craver ) 29 января 2013 г.

забавный факт: StackOverflow используется для обработки выхода через GET, но не больше.

Answer 2

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

На самом деле вы спрашиваете, должен ли браузер продолжать посылать аутентификационную информацию при каждом запросе.

Возможно, если ваше приложение создает иллюзию входа в систему, то вы должны иметь возможность "выйти", используя javascript. Туда и обратно не требуется.

---

Филдинг Диссертация - Раздел 5.1.3

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

Answer 3

Одним из способов злоупотребления GET здесь является то, что человек (возможно, конкурент :) разместил тег изображения с src="<your logout link>" В ЛЮБОМ месте в Интернете, и если пользователь вашего сайта наткнется на эту страницу, он будет неосознанно вышли из.

Answer 4

Чтобы быть точным, GET / POST (или другие глаголы) - это действия над каким-либо ресурсом (с помощью URL), поэтому обычно речь идет о состоянии ресурса, а не о состоянии приложения как такового.Так что в истинном духе у вас должен быть URL, такой как [host name]\[user name]\session, тогда «DELETE» будет правильным глаголом для действия по выходу из системы.

Использование [host name]\bla bla\logout в качестве URL в действительности не является полным REST (ИМО), так зачем спорить о правильном использовании GET / POST на нем?

Конечно, я также использую GET для выхода из URL в своих приложениях: -)

Answer 5

Выход из системы никак не влияет на само приложение. Изменяет состояние пользователя по отношению к приложению. В этом случае кажется, что ваш вопрос больше основан на том, как команда должна быть инициирована пользователем, чтобы начать это действие. Поскольку это не «разрушительное действие», убедитесь, что сеанс отменен или уничтожен, но ни ваше приложение, ни ваши данные не изменены, поэтому невозможно, чтобы оба метода инициировали процедуру выхода из системы. Сообщение должно использоваться любыми действиями, инициированными пользователем (например, пользователь нажимает кнопку «Выйти»), в то время как get может быть зарезервировано для инициированных приложением выходов из системы (например, исключение, обнаруживающее потенциальное вторжение пользователя, принудительно перенаправляет на страницу входа с выходом из системы GET ).

Answer 6

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

CREAT token => method POST

Когда вы выходите из системы, вы уничтожаете токен, поэтому наиболее логичным для меня должен быть метод DELETE

DELETE token => method DELETE

Answer 7

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

Или, возможно, ссылка может быть реализована в javascript?

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

Answer 8

Я не вижу, как выход из системы (снижение прав пользователей) является деструктивным действием.Это связано с тем, что действие «выход из системы» должно быть доступно только тем пользователям, которые уже вошли в систему, иначе оно будет устаревшим.

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

Answer 9

Что ж, если вы позволите своему веб-приложению отказаться от сеанса с помощью сценария выхода из системы, то обычно вам это тоже не нужно.Обычно есть переменная сеанса, уникальная для сеанса, который вы хотите отменить.