シナリオ
通信アプリケーション用のカスタムCMSを構築しています。ユーザーは画像をサーバーにアップロードし、後でマークダウンを使用して書き込んだ投稿でそれらを参照できます。画像はデータベースに保存され、フォームのURLで参照されますimages/{id}。カスタムイメージハンドラーはこれらを取得し、遠い将来の期限切れヘッダーを設定して、何度もフェッチされないようにします。ファイルシステムに画像を保存することは、顧客ごとのオプションではありません。
投稿は、パフォーマンスのためにマークダウンおよびhtmlとしてデータベースに保存されます。
マークダウン
###Header
Lorem Ipsum dolor sit amet. 
HTML
<h3>Header</h3>
<p>
Lorem Ipsum dolor sit amet. <img alt="funny cat" src="images/25" />
</p>
問題
これらの画像も編集可能です。キャッシングの観点からは、これには問題があります。画像を編集するときは、ブラウザが最新バージョンを取得していることを確認する必要があります。私は次の解決策を考え出しましたが、それらすべてに欠けていることがわかりました。
可能な解決策
バージョンフィールド
画像とともにバージョンフィールドを保存します。画像が編集されたときにそれをインクリメントして、フォームのURLを生成しimages/{id}/version/{version}ます。
これは、画像のURLが常にデータベースから生成される場合に便利です。ただし、URLをテキストとして投稿に保存しているため、これらのリクエストに対して、場合によっては大量のテキストを前処理する必要があります。また、画像を編集するとURLが古くなるため、画像のリンクが面倒になります。これはおそらく良い考えではありません。
新しいURL
画像を編集したら、それを新しいエントリとしてデータベースに保存します。
これはバージョンの維持がないことを意味しますが、古いリンクと古い投稿には同じ問題があります。それらは決して更新されません。パフォーマンスは良好ですが、問題は残ります。
304-変更なし
各画像の最後に編集したフィールドを保存します。条件付きリクエストが返されると、httpステータス304-変更なし、帯域幅の使用量が削減されます。
これは私がこれまでに得た最良の解決策のようです。編集しない限り画像はキャッシュされますが、私はこれまでこのアプローチを使用したことがありません。ページに50枚の画像がある場合でも、サーバーへのリクエストは50枚あります。帯域幅は減少しますが、遅延は残ります。このアプローチはそのコストに見合う価値がありますか？
質問
私はこの分野での経験がほとんどないので、皆さんがもっと経験を積んでくれることを願っています。上記の解決策のいずれかが実行可能ですか？もしそうなら、彼らとのあなたの経験は何ですか？そうでない場合、より良いアプローチは何ですか？