REST-приложение, транзакции, сброс кэша

Question

Я строю REST API в php со слоем memcache сверху для кэширования всех ресурсов. После некоторого чтения / опыта выясняется, что лучше всего, когда документы настолько просты, насколько это возможно ... в основном из-за удаления последовательностей кэша.

Таким образом, если для документа "комната" есть сущности "здание", "комната", я бы указывал только идентификатор "здания", а не все его данные. Затем на стороне клиента API я бы объединял данные по мере необходимости.

Проблема возникает, когда мне нужно обновить / вставить (в большинстве случаев более одной таблицы). Я обновляю один ресурс, но во втором обновлении происходит сбой системы или что-то еще, и возникают несоответствия базы данных.

Я вижу несколько решений:

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

2. При действиях обновления / вставки я передаю более сложные данные (не отдельные объекты), чтобы можно было форсировать транзакции на уровне API. Но это сделает странным, что ваша структура документа GET такая же, как структура документа PUT. И снова как-то сделать сложную последовательность сброса.

Любые указатели приветствуются. Cheers,

Answer 1

То, что вы хотите сделать, это что-то вроде:

Клиент <-> Прокси-кеш (например, Squid) <-> REST интерфейс <-> memcached <-> Доменная модель

Если вы в полной мере используете кеширование HTTP, вам может не понадобиться слой memcached. Аннулирование кэша - неприятная проблема, и в HTTP уже есть множество правил и механизмов, которые помогут вам оставаться в здравом уме. Я не очень знаком с memcached, но быстрый гугл на эту тему, кажется, указывает на то, что вам нужно развернуть свою собственную стратегию аннулирования кэша. HTTP имеет дополнительное преимущество, заключающееся в возможности кэшировать данные и на стороне клиента.

Если у вас есть сценарии, в которых клиенту необходимо обновить несколько объектов домена одновременно, вам необходимо создать ресурсы в интерфейсе REST, которые представляют виртуальные «составные» объекты. Клиент должен воспринимать только то, что он обновляет один ресурс. За кулисами вы можете обновить несколько ресурсов в транзакции базы данных, если хотите.

REST-системы легче создавать, если вы сопоставите свои ресурсы с PresentationModels . Ошибка, которую совершает большинство людей, заключается в том, что они пытаются строго сопоставить ресурсы REST с объектами домена. Может быть тесная корреляция, но это не будет прямым отображением, если у вас нет действительно скучного приложения!