Comme indiqué dans les commentaires, c'est mieux pour avoir un point de terminaison distinct dans votre application pour que ces appels "ressemblent" à des demandes de fichiers statiques standard. Alors la première chose que je changerait un peu votre schéma :
picture: {
metadata: {
name: { type: String, default: null },
comment: { type: String, default: null },
publisherID: { type: String,default: null },
date: { type: Date, default: Date.now },
size: { type: Number,default: 0 },
type: { type: String, default: null }
},
path: { type: String, required: true },
mime: { type: String, required: true },
data: { type: Buffer, default: null },
tags: Array
}
Cela ajoute donc deux champs qui vont identifier le "chemin" de l'image à faire correspondre, et "mime" comme type mime du fichier. Donc "path" est un identifiant plus "convivial" qu'un _id et le "mime-type" serait défini dans insert pour correspondre au type de contenu renvoyé.
Ensuite, vous configurez une route pour diffuser le contenu :
app.get('/images/:imgname', function(req,res) {
Picture.find({ "picture.path": req.param("imgname") }, function(err,pic) {
if (err) // checking here
// Sending response
res.set('Content-Type', pic.mime);
res.send( pic[0].picture.data );
});
})
Ainsi, lorsque vous avez fait une requête comme :
Cela arriverait :
-
Trouvez le document correspondant au "chemin" pour "test.png"
-
Attribuez la propriété de document pour "picture.mime" comme Content-Type pour la réponse
-
Renvoyer les données binaires comme réponse
Donc, pour le client, c'est un fichier réel comme réponse, et le fait est que le "navigateur" peut mettre en cache ceci et pas touché votre application où la copie "en cache" est valide.
Si vous intégrez des données encodées en Base64 dans les réponses JSON, vous perdez cette partie importante et vous envoyez les données à chaque fois. C'est aussi un processus très compliqué à gérer, comme vous l'avez découvert.
