2016-06-17 3 views
0

データモデルがユーザープロファイルであるとします。各レコードは、name,age,portraitなど(portraitは画像)です。対応するRESTful要求が来る前にアップロードされたファイルを管理する方法

フロントエンドの編集ページでは、選択した直後にポートレート画像をアップロードして、最後の送信に時間がかかりません。

open front-end editing page 
    | 
    | 
edit some fields 
    | 
    | 
select an image for portrait ---. 
    |       | 
    |       | 
    |     uploading...may take a while 
    |       | 
grab a cup of coffee   | 
    |       | 
    |       | 
edit other fields    | 
    |       | 
    |     upload finished 
    |       | 
    |---------------------------' 
    | 
submit       
    |       
    | 
respone 

submitステップは、実際に{ name: 'John', age: 20, portrait: 'what should be here?' }ようなものでバックエンドにPOSTリクエストを送信しています。問題は、要求データのportraitフィールドにあるべきものですか?

アイデアを思いつきましたが、より良いものがあるかどうかわかりません。 バックエンドは、画像アップロードに対する応答として画像リソースを表すトークンを返します。フロントエンドはportraitフィールドに設定されたそのトークンでデータを送信します。

もう1つ質問があります。ユーザーが編集をキャンセルしたらどうなりますか?アップロードされたファイルはまだサーバーのストレージに存在し、クリーンアップする必要があります。おそらく、ユーザーが「キャンセル」ボタンをクリックしたときにトークンを送信することができます。しかし、ユーザーが「キャンセル」ボタンをクリックせずに編集ページを出るだけの場合はどうでしょうか?

これを行うのがベストプラクティスですか?

答えて

0

Paulは、アップロードされたドキュメントの識別子について正しい考えを持っています。

さらに、ユーザーが編集をキャンセルした場合はどうなりますか?アップロードされたファイルはまだサーバーのストレージに存在し、クリーンアップする必要があります。おそらく、ユーザーが「キャンセル」ボタンをクリックしたときにトークンを送信することができます。しかし、ユーザーが「キャンセル」ボタンをクリックせずに編集ページを出るだけの場合はどうでしょうか?

ユーザーがキャンセルボタンをクリックしたとしても、その信号は実際にサーバー(信頼性の低いネットワーク)に配信されないことがあります。

放棄された画像を識別できるものと、それらを削除する機能が必要です。サーバーでこのクリーンアップを行うこともできますし、APIをリモートで制御できるようにリソースを公開することもできます。

関連する問題