Вихід: GET або POST?

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

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

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

Все, що я читав до цього часу, говорить про те, що POST слід використовувати для "руйнівних дій", тоді як дії, які не змінюють внутрішній стан запиту, подібного до додатків, і таке - слід обробляти з GET . Виходячи з цього, справжнє питання тут:

Чи вважається вихід із програми деструктивним чи змінює внутрішній стан програми?

Використовуйте POST.

У 2010 році використання, GETмабуть, прийнятної відповіді. Але сьогодні (у 2013 році) браузери заздалегідь зароблять сторінки, які вони "думають", що ви відвідаєте наступне.

Ось один із розробників StackOverflow, який розповідає про цю проблему на Twitter:

Хочу подякувати своєму банку за те, що він вийшов із запиту GET, та команді Chrome за зручне попереднє завантаження URL-адрес. Нік Крейвер ( @Nick_Craver ) 29 січня 2013 року

цікавий факт: StackOverflow використовується для обробки виходу через GET, але вже не.

У REST не повинно бути сеансу, тому руйнувати немає чого. Клієнт REST аутентифікується на кожен запит. Увійшов або вийшов, це просто ілюзія.

Що ви насправді запитуєте, чи повинен браузер продовжувати надсилати інформацію про автентифікацію на кожен запит.

Імовірно, якщо ваша програма створює ілюзію входу в систему, ви повинні мати можливість "вийти" за допомогою JavaScript. Жодна поїздка не потрібна.

Польова дисертація - Розділ 5.1.3

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

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

Щоб бути правильним, GET / POST (або інші дієслова) - це дії на певному ресурсі (адресованому URL-адресою) - тож загалом про стан ресурсу, а не про стан програми як такого. Тож у справжніх духів у вас повинна бути така URL-адреса, як [host name]\[user name]\session, то "DELETE" - це правильне дієслово для виходу з системи.

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

Звичайно, я також використовую GET для URL виходу у своїх програмах :-)

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

Привіт, на мій погляд, коли ви входите, ви перевіряєте ім'я користувача / пароль, і якщо вони відповідають вам, ви створюєте маркер входу.

CREAT token => метод POST

Коли ви виходите з системи, ви відволікаєте маркер, тому для мене самим логічним методом має бути ВИКОРИСТАННЯ

DELETE token => метод DELETE

Сценарій попереднього кешування є цікавим. Але я здогадуюсь, що якщо багато сайтів, включаючи ТАК, не переживайте з цього приводу, то, можливо, ви й не повинні.

Чи, можливо, посилання може бути реалізовано в JavaScript?

Редагувати: Як я розумію, технічно GET повинен бути для запитів лише для читання, які не змінюють стан програми. POST повинен бути для запитів / редагування запитів, які змінюють стан. Однак інші проблеми з додатком можуть віддати перевагу GET over POST для деяких запитів, що змінюються державою, і я не думаю, що в цьому є проблеми.

Добре, якщо ви забороняєте веб-програмі відмовлятися від сеансу через сценарій виходу, зазвичай вам це також не потрібно. Зазвичай існує змінна сесія, яка є унікальною для сеансу, який ви бажаєте залишити.

Нещодавно я працював над проектом, який використовую GET для виходу. Нижче є код у Nodejs Express, і він працює чудово

ваш router.js

const express = require("express");
router.get("/signout", signout);

ваш controller.js

exports.signout  = (req, res) => {
        res.clearCookie('t'); //clearing cookie, which is 
            //assign to the user during sign in.          
            res.json({message : 'Signout success'});   
        };

Я не бачу, наскільки виїзд (зменшення дозволів користувача) є дескруктивною дією. Це тому, що дія "виходу" має бути доступною лише тим користувачам, які вже ввійшли в систему, інакше це буде застарілим.

Випадково створена рядок, що міститься у файлах cookie вашого браузера, - це все, що представляє вашу сесію користувача. Існує безліч способів знищити його, щоб настільки ефективно вийти з системи - це лише послуга для вашого відвідувача.