Когда REST API перестает быть таковым с точки зрения управления состоянием?

Когда REST API перестает быть таковым с точки зрения управления состоянием?
Когда REST API перестает быть таковым с точки зрения управления состоянием? - jonathanmast @ Unsplash

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

Я читал о том, что stateless - это отсутствие короткоживущих состояний. Состояние, хранящееся в базе данных, нормально и т.д.

Например, общепринятая идея о хранении JWT-токена где-то рядом, скажем, с контекстом безопасности Spring или использование Redis для кэширования склоняется к тому, что они вредят RESTness или они в порядке, пока у них есть короткоживущее состояние?

Буду признателен за любую предложенную литературу. Заранее спасибо.

Отсутствие статичности в REST означает, что состояние транзакции не сохраняется между запросами.

Например, у меня есть API электронной коммерции, где я могу купить "корзину" товаров.

API без состояния может представлять

  • ListItemsForSale()
  • NewBasket(customer)
  • AddItem(item)
  • PurchaseBasket(paymentDetails)

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

С другой стороны, Stateless API будет раскрывать

  • ListItemsForSale()
  • BuyBasket(items, customer, paymentDetails)

Поскольку он не поддерживает состояние каждого клиентского заказа, вы должны отправлять всю информацию, необходимую для транзакции, в одном запросе и поддерживать состояние на стороне клиента.

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

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

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


LetsCodeIt, 21 февраля 2023 г., 01:42