Чи порушують сеанси на стороні сервера REST?

За словами Роя Філдінга (одного з основних авторів специфікації HTTP), у своїй тематичній дисертації « Архітектурні стилі» при обговоренні REST він згадує:

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

Під "збереженим контекстом" він має на увазі стан програми, наприклад, який номер сторінки для наступної сторінки відповідає стану ресурсу, наприклад, будь-який сховище даних, зображення тощо - що, мабуть, вся суть REST.

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

Поняття сеансу є загальним - зокрема, для веб-розробників - але чи це RESTful відповідно до наведеного вище визначення?

Я б сказав, що так, стан сеансу робить додаток RESTful не-RESTful. Тривіальний приклад, моя сестра підписується на журнал Wall Street Journal. Вона регулярно читатиме щось за платною стіною і вирішить надіслати посилання (через власний клієнт електронної пошти, а не через WSJ) другові, який не має облікового запису WSJ. Клацніть, надішліть, не вдасться. Очевидно, що досвід моєї сестри за цією URL-адресою відрізняється від досвіду її друга.

Пов’язана, але не строго тематична тема: я перебуваю на початковій стадії розробки програми, розробленої для підтримки значних зусиль у мережі (називаються квести (подумайте: закладки на стероїди та LSD)). Власник квесту хоче поділитися певним видом своїх даних з кимось іншим, але цей погляд вимагає комбінації стану користувальницького інтерфейсу (наприклад, які візуалізації даних, які відображаються на яких панелях), а також відповідні дозволи на доступ до інтерфейсу користувача і відображаються дані. Отримувачу потрібна велика кількість збереженого стану, щоб отримати призначений вид.

Моє поточне рішення - зберігати весь інтерфейс користувача / ACL / будь-яку інформацію, необхідну для перегляду, в окремому об'єкті та повертати URL-адресу (можливо, UUID) для цього об’єкта. Я вважаю, що доступ до об’єкта перегляду можна вважати ВІДКРИТИм у тому сенсі, що кожен, хто ним володіє, отримує однакову інформацію / досвід.

Чи порушують сеанси на стороні сервера REST?

Вони точно роблять! Під час реалізації REST не повинно бути сеансів на стороні сервера, інакше у вас є гібридне рішення RPC / REST.

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

Напевно, залежить від того, що ви маєте на увазі під "сеансовими даними". Це точний термін?

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

Я був би дуже здивований, якби цей вид операцій був позначений як НЕБЕЗПЕЧНИЙ. OAuth - приклад.

Я не фахівець і тут не дуже впевнений; Я просто ділюся своїми думками, сподіваючись, що вони виявляться корисними.

Найважливішим моментом REST є те, що URI до ресурсу завжди вказує на той самий ресурс. Таким чином, користувачі можуть пройти посилання на цей ресурс, і всі бачать те саме. Це називається Представницький державний трансфер (REST). Якщо сервер зберігає стан і доставляє інший ресурс для того ж URI, я б сказав, що це вже не є чистим REST.

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

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

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

Філдінг мається на увазі під тим твердженням, що сервер додатків, що розміщує API REST, не пов'язує оточуючий стан із запитом якогось механізму поза кадром. Розглянемо різницю між сервером програми та сервером баз даних . Обмеження REST полягає в тому, що сервер додатків повинен бути без стану . Однак сервер додатків може делегувати запити на стан ресурсу на сервер бази даних на основі інформації, яка є частиною запиту, наприклад комбінації користувача / пароля в заголовку авторизації або самого Uri. Зрештою, REST заснований на моделі клієнт / сервер.