Application REST, Transactions, Cache drop

Question

Je construis l'API REST en php avec la couche memcache en haut pour la mise en cache de toutes les ressources. Après quelques lectures/expériences, il s'avère que c'est mieux quand les documents sont aussi simples que possible ... principalement en raison de la chute des séquences de cache. Donc s'il y a des entités 'building', 'room' pour le document 'room', je ne placerais que l'identifiant du 'building' et non pas l'ensemble des données. Ensuite, côté client api, je fusionnerais les données si nécessaire.

Problème devient quand j'ai besoin de mettre à jour/insérer (la plupart des cas plus d'une table). Je mets à jour une ressource mais sur le deuxième système de mise à jour échoue ou peu importe et il y a des incohérences de base de données.

Je vois plusieurs solutions:

1. Mettre en oeuvre des opérations de repos que je trouve mal et complexe idée est d'être apatride et facile. Lors des actions de mise à jour/d'insertion, je transmets des données plus complexes (pas des entités uniques), ce qui me permet de forcer des transactions au niveau de l'API. Mais cela rendra étrange que votre structure de document GET soit la même que la structure du document PUT. Et encore une fois faire des séquences de chute complexes.

Les pointeurs sont plus que bienvenus. Vive,

Answer 1

Qu'est-ce que vous voulez faire est quelque chose comme:

client < -> cache proxy (comme Squid) < -> interface REST < -> memcached < -> Modèle de domaine

Si vous utilisez pleinement la mise en cache HTTP, vous n'aurez peut-être pas du tout besoin de la couche memcached. L'invalidation de cache est un problème désagréable à résoudre et HTTP a beaucoup de règles et de mécanismes déjà en place pour vous garder sain. Je ne suis pas très familier avec memcached mais un google rapide sur le sujet semble indiquer que vous devez lancer votre propre stratégie d'invalidation de cache. HTTP a également l'avantage de pouvoir mettre en cache des éléments du côté client.

Si vous avez des scénarios dans lesquels le client doit mettre à jour plusieurs objets de domaine à la fois, vous devez créer des ressources dans l'interface REST qui représentent des objets «composites» virtuels. Le client doit seulement percevoir qu'il met à jour une seule ressource. Dans les coulisses, vous pouvez mettre à jour plusieurs ressources dans une transaction de base de données si vous le souhaitez.

Les systèmes REST sont plus faciles à créer si vous mappez vos ressources sur votre PresentationModels. L'erreur que font la plupart des gens consiste à essayer de faire correspondre strictement les ressources REST aux objets du domaine. Il peut y avoir une corrélation étroite, mais ce ne sera pas une cartographie directe sauf si vous avez une application vraiment ennuyeuse!