Насколько я понимаю, не существует определенных границ для REST-версии API. Тем не менее, я хотел бы получить вашу помощь, чтобы понять, насколько большой и длительный (с точки зрения времени работы) механизм кэширования или управления состоянием было бы нормально использовать с учетом цели REST API.
Я читал о том, что stateless - это отсутствие короткоживущих состояний. Состояние, хранящееся в базе данных, нормально и т.д.
Например, общепринятая идея о хранении JWT-токена где-то рядом, скажем, с контекстом безопасности Spring или использование Redis для кэширования склоняется к тому, что они вредят RESTness или они в порядке, пока у них есть короткоживущее состояние?
Буду признателен за любую предложенную литературу. Заранее спасибо.
Отсутствие статичности в REST означает, что состояние транзакции не сохраняется между запросами.
Например, у меня есть API электронной коммерции, где я могу купить "корзину" товаров.
API без состояния может представлять
клиент будет вызывать каждый из них по очереди, а API будет отслеживать содержимое корзины и клиента на протяжении всей транзакции.
С другой стороны, Stateless API будет раскрывать
Поскольку он не поддерживает состояние каждого клиентского заказа, вы должны отправлять всю информацию, необходимую для транзакции, в одном запросе и поддерживать состояние на стороне клиента.
Такие вещи, как подключение к базе данных и api ключи, являются состоянием сервера. Они не связаны с отдельными клиентскими транзакциями, и вам не нужно учитывать их для S в REST.
Когда API сохраняет информацию о клиенте в базе данных, скажем, после покупки корзины здесь сохраняется ваш заказ для обработки, это может быть серой зоной. Но в целом это не считается, если это конечное состояние транзакции.
Таким образом, если бы вы реализовали мой пример с состоянием в базе данных, чтобы избежать состояния в памяти на API, вы бы в конечном итоге получили множество не купленных, брошенных корзин с течением времени. REST говорит, что хранение этого состояния в API - это плохо, что вы можете лучше масштабироваться и иметь лучший API, если не будете этого делать.