it-swarm.com.ru

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

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

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

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

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

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

357
Daniel Liuzzi

Используйте POST.

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

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

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

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

406
David Murdoch

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

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

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


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

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

39
Darrel Miller

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

36
raveren

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

Использование [Host name]\bla bla\logout в качестве URL-адреса не совсем REST полным способом (IMO), так зачем спорить о правильном использовании GET/POST для него?

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

18
VinayC

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

14
Joel Etherton

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

CREAT token => method POST

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

УДАЛИТЬ токен => метод УДАЛИТЬ

10
miorey

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

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

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

1
Richard H