Понимание REST с точки зрения масштабируемости, производительности,

Question

Я просто хочу знать, правильны ли мои мысли о REST.Давайте представим, что у нас есть торговый сайт.При традиционном подходе корзина покупок будет храниться в сеансе пользователя, так что серверу придется управлять многими элементами для пользователя (Пользователь № 1: элемент 1, элемент 2, элемент 3; Пользователь № 2: элемент A, элемент B, элемент 3, ...),Таким образом, сервер должен обладать большой памятью / вычислительной мощностью, если более тысячи пользователей просматривают сайт и добавляют товары в свою корзину.

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

Теперь, если я добавлю элемент в не-REST-подходе к корзине покупок, он будет идти прямо в сеансе.Если я добавляю элемент в REST-подходе, мне нужно обновить сущность в базе данных (/ shoppingcart / 1234 /), и это займет немного больше времени, так как мне придется идти на один уровень глубже (client-> server-> database),

Правильно ли это до сих пор или я упускаю или неправильно понимаю точку?

Answer 1

В подходе REST сеанс отсутствует, поэтому у клиента есть вся информация о товарах в корзине.

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

Рассмотрим следующий URL:

/ корзины покупок / john.howes

Мое понимание ограничения безгражданства заключается в том, что если я, вы или кто-либо перейдете по этой ссылке, мы получим некоторое представление об одном и том же ресурсе (при условии, что у нас есть разрешение на его просмотр). Это может быть XML или JSON или HTML, и это может быть на английском или французском языке, но базовый ресурс тот же. И если я добавлю этот URL-адрес в закладки и просмотрю его позже на другом устройстве или отправлю его другу по электронной почте, мы получим тот же ресурс (при условии, что он все еще существует и у нас есть разрешение на его просмотр).

Итак, поскольку у меня была ссылка на /shopping-cart/john.howes, у меня была вся информация, необходимая для обслуживания запроса.

Теперь, если я добавлю товар в не-REST-подходе в корзину, он будет идти прямо в сеансе. Если я добавляю элемент в REST-подходе, мне нужно обновить сущность в базе данных (/ shoppingcart / 1234 /), и это займет немного больше времени, так как мне придется идти на один уровень глубже (client-> server-> database) .

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

Надеюсь, это поможет.

John

Answer 2

Существует два разных способа сделать корзину покупок в REST.Во-первых, вы фактически делаете корзину покупок ресурсом и назначаете ему URI, как вы описываете.Во-вторых, содержимое корзины покупок хранится на клиенте вплоть до момента, когда пользователь размещает заказ.

Есть плюсы и минусы для обоих подходов, и да, хранение корзины покупок какресурс потребует сохранения корзины покупок в базе данных (хотя это может быть база данных в памяти!).

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