Выход: GET или POST?

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

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

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

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

Это выход приложения, рассматриваемого как деструктивное действие/изменяет ли оно внутреннее состояние приложения?

9 ответов


использовать POST.

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

вот один из разработчиков StackOverflow говорит об этой проблеме в twitter:

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

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


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

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

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


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

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


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


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

используя [host name]\bla bla\logout как URL-адрес на самом деле не REST full way (IMO), так зачем спорить о правильном использовании GET/POST на нем?

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


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


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

CREAT token = > метод в должности

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

удалить маркер => метод удалить


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

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

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


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


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

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