API RESTful должны быть без сохранения состояния, но как насчет параллелизма? - PullRequest
9 голосов
/ 24 марта 2012

Мне интересно, как я решаю проблему параллелизма для RESTful API. Более конкретно, у меня есть коллекция объектов, которые требуют ручного изучения и обновления, например, количество строк, которым необходимо обновить столбец вручную; однако, если я открою API для нескольких клиентов, все они будут получать эти элементы сверху вниз, поэтому многие пользователи будут заполнять столбец одной и той же строки одновременно. Я бы предпочел, чтобы не было коллизий, и простой способ с отслеживанием состояния состоит в том, чтобы просто помещать элементы в очередь в службе и извлекать их, когда люди их запрашивают.

Что это за версия без состояния? Хеширование по IP-адресу или случайное получение строк по идентификатору?

:: update ::

"Хм, значит, он просто не должен иметь состояния с точки зрения клиента?

Это, безусловно, имеет большой смысл. Я только что читал статью (ibm.com/developerworks/webservices/library/ws-restful) о API-интерфейсах RESTful, и, столкнувшись с информацией о разбиении на страницы, я побеспокоился о том, что моя очередь с полным состоянием была похожа на увеличение на страницу, но на самом деле они совершенно разные, поскольку «следующая страница» относительна на стороне клиента, тогда как «pop» для клиента всегда не имеет состояния: не имеет значения, что было добавлено ранее.

Спасибо, что очистили мою голову! "-Ме

Ответы [ 2 ]

5 голосов
/ 25 марта 2012

Существует два основных подхода:

  1. Перейдите полностью без сохранения состояния и примите стратегию «последний запрос выигрывает». Как бы странно это ни звучало, это, вероятно, самое чистое решение 1006 * с точки зрения предсказуемости, масштабируемости, сложности кода и реализации как на стороне клиента, так и на стороне сервера. Для этого также есть много преимуществ: посмотрите, как такие сайты, как Google, разбивают на страницы для запросов, используя start=10 для страницы 2, start=20 для страницы 3 и т. Д.

    Вы можете обнаружить, что содержимое меняется на страницах при перемещении между ними, но что с того? Вы всегда получаете самую свежую информацию, и Google может обрабатывать ваши запросы на любом из своих многочисленных серверов без необходимости поиска информации о сеансе, чтобы определить, каким был ваш последний контекст запроса.

    Самым большим преимуществом этого подхода является простота реализации вашего сервера. Каждый запрос может просто передаваться прямо на уровень данных на внутреннем уровне, и он абсолютно готов для кэширования как на уровне HTTP (через E-Tags или заголовки Last-Modified), так и на стороне сервера (используя что-то вроде memcache, для пример).

  2. Идите с отслеживанием состояния и найдите способ заставить ваши серверы выдавать какую-то блокировку или маркер для каждого клиента для каждого "сеанса" API. Это все равно что пытаться бороться с приливом океана с помощью палки, потому что вы в конечном итоге потерпите неудачу и будете разочарованы.

    Как вы будете идентифицировать клиентов? Ключи сеанса? Айпи адрес? Файловый дескриптор сокета, по которому они въехали (удачи вам, если вы используете транспорт, такой как HTTP, где соединение может быть закрыто между запросами ...)? Детали, которые вы выберете для этого, должны будут быть сохранены на стороне сервера, или вам придется использовать некую старую липкую функцию сессии на вашем сервере приложений (и если да, то небеса помогут вашему клиенту, если сервер, который они используют, выйдет из строя середине сеанса).

    Как вы будете обращаться с API-клиентами, которые исчезают изящно? Будете ли вы автоматически устанавливать тайм-ауты их сессионных блокировок, когда поток жнецов очищает свободные Это больше кода, больше сложности и больше мест для скрытия ошибок. А как насчет API-клиентов, которые возвращаются после долгого простоя и пытаются повторно использовать блокировку с истекшим сроком, как должны создаваться клиентские приложения для обработки такой ситуации?

Я мог бы продолжить, но, надеюсь, вы понимаете мою точку зрения. Перейти с вариантом 1 и перейти без гражданства. В противном случае вы в конечном итоге попытаетесь отследить состояние клиента на стороне сервера. И единственное, что должно отслеживать состояние клиента, - это сам клиент.

1 голос
/ 02 июня 2013

Можно поддерживать состояние ресурса. «Запрет без сохранения состояния» относится только к состоянию сеанса.

Вот выдержка из оригинального REST-вывода Роя Филдинга :

Затем мы добавим ограничение к взаимодействию клиент-сервер: общение должно быть без гражданства по своей природе, как в стиль клиента-состояния-сервера (CSS) раздела 3.4.3 (рисунок 5-3), так что каждый запрос от клиента к серверу должен содержать все информация, необходимая для понимания запроса, и не может принять преимущество любого сохраненного контекста на сервере. Состояние сеанса поэтому держится целиком на клиенте.

...