Лекція 2.1. Використання RESTful

5. Незбереження стану

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

При обробці повного самодостатнього запиту серверу не потрібно витягувати стан або контекст програми. Застосунок (або клієнт) Web-сервісу REST включає в HTTP-заголовки і в тіло запиту всі параметри, контекст і дані, необхідні серверному компоненту для генерування відповіді. У цьому сенсі незбереження стану (statelessness) покращує продуктивність Web-сервісу і спрощує дизайн і реалізацію серверних компонентів, оскільки відсутність стану на сервері усуває необхідність синхронізації сеансових даних із зовнішнім застосунком.

На рисунку 1 показаний сервіс, що зберігає стан, в якому застосунок може запитати наступну сторінку в багатосторінковому наборі результатів, вважаючи, що сервер зберігає послідовність переходів застосунку з цього набору результатів. У цій моделі зі збереженням стану сервіс нарощує і зберігає змінну previousPage, щоб бути в змозі відповідати на запити наступних сторінок.

Рисунок 1. Модель зі збереженням станів

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

На противагу цьому, серверні компоненти що не зберігають стан більш прості в проектуванні, написанні та розподілі між серверами зі збалансованим навантаженням. Сервіс, що не зберігає стан,  не тільки краще працює, але і покладає основну відповідальність за збереження стану на клієнтську програму. У Web-сервісі RESTful сервер відповідає за генерування відповідей і за надання інтерфейсу, що дозволяє клієнтському застосунку самому зберігати свій стан. Наприклад, при запиті багатосторінкового набору результатів клієнтський застосунок повинен включати в запит номер конкретної сторінки, а не просто запитувати наступну сторінку (див. Рисунок 2).

Рисунок 2. Модель без збереження стану

Web-сервіс, що не зберігає стану, генерує відповідь, що містить посилання на номер наступної сторінки в наборі і дозволяє клієнтові самостійно подбати про збереження цього значення