コメントで述べられているように、それはより良いです これらの呼び出しを標準の静的ファイル要求のように「見せかける」ために、アプリケーションに個別のエンドポイントを設定します。だから最初に私 スキーマを少し変更するだけです：
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
}
これにより、一致する画像への「パス」と、ファイルのmimeタイプとしての「mime」を識別する2つのフィールドが追加されます。したがって、「パス」は_idよりも「わかりやすい」識別子です。 「mime-type」は、返されたコンテンツタイプと一致するように挿入で設定されます。
次に、コンテンツを提供するためのルートを設定します。
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 );
});
})
したがって、次のようなリクエストを行った場合：
これは起こります：
-
「test.png」の「パス」に一致するドキュメントを検索します
-
「picture.mime」のドキュメントプロパティを応答のコンテンツタイプとして割り当てます
-
バイナリデータを応答として送り返します
したがって、クライアントの場合、これは応答としての実際のファイルであり、要点は「ブラウザ」がキャッシュできるということです。 これとヒットしない 「キャッシュされた」コピーが有効なアプリケーション。
Base64でエンコードされたデータをJSON応答に埋め込む場合は、緩めます その重要な部分とあなたは毎回データを送信します。ご存知のように、これは処理が非常に面倒なプロセスでもあります。