Antichesse (o ^ω^ o)
Effectivement je n'y avais pas pensé : les réponses des requêtes JSON qu'effectue une PWA peuvent être mises en cache par le navigateur lui-même. Ce faisant, la seconde fois qu'une requête est jouée, la réponse de celle-ci peut ne pas avoir de résultat à jour.
Ceci dit, lorsque le serveur ajoute en entête de message qu'il répondra du "application/json", il me semble que le navigateur téléchargera toujours ce contenu à l'image de ce qu'il fait pour une page HTML (sauf si un cache contrôle est défini côté serveur avec une durée supérieure à zéro).
Le mieux étant de faire comme le dit Timo, à savoir ajouter côté serveur l'option
Cache-Control: max-age=0
Rappel des définitions
PWA : Progressive Web App.
SPA : Single Page Application (voir ce post).
Introduction
Une PWA est fondamentalement une SPA à laquelle a été ajouté deux choses :
- Elle se comporte comme une application native sur les appareils (Mobile, Tablette et PC).
En d'autres termes, l'utilisateur trouvera sur son bureau une icône du site web développé à partir de la technologie PWA.
Elle peut travailler en mode déconnecté via ce que l'on appelle les Service Workers.
Fondamentalement qu'est-ce que ça change ?
Côté mobile, l’utilisateur installe la PWA de deux façons :
- Soit via un simple bookmark posé sur son bureau.
- Soit via un AppStore qui lui créera une icône sur son bureau.
Il a dont l'impression "d'installer une appli" et non plus de "surfer sur internet".
Si une panne de réseau survient, les Service Workers de la PWA vont prendre le relais et :
- Soit empiler les requêtes en fournissant les données précédentes.
- Soit en calculant les données requises (si possible).
Le Service Worker agit donc un peu comme un proxy, mais côté client, à qui le navigateur délègue l'accès au réseau.
Le gros avantage de la PWA sur les applications natives est qu'il n'est plus nécessaire de développé une version de GUI par plateforme mais tout via des technos web (Aurelia, Angular, Vue, etc).
