ユーザーができるファイルアップロードサービス用にREST APIを作成する必要があります。
その後、戻ってきて、前のセッションでアップロードしたファイルを使用して処理を行います。
各ファイルに関するデータの処理とファイル自体のコンテンツの処理を容易にするために、これは私が使用することを考えているURIスキームです。
/sessions/
/sessions/3
/sessions/3/files
/sessions/3/files/5
/sessions/3/file/5/content
/sessions/3/file/5/metadata
これにより、ファイルメタデータをファイルコンテンツとは別に処理できるようになります。この場合、ファイルcontentおよびファイルmetadataではGETのみが許可され、いずれかを更新するには、新しいファイルをPUTする必要があります。
これは理にかなっていますか?そうでない場合、なぜ、どのように改善することができますか?
なぜセッションが必要なのですか?認証と承認の理由ですか?その場合、http basic with SSLまたは digest を使用します。そのため、httpはステートレスであり、セキュリティヘッダーが各リクエストで送信されるため、開始セッションまたは終了セッションはありません。
アップロードリソースの提案は、プライベートファイルシステムとして直接マッピングすることです。
# returns all files and subdirs of root dir
GET /{userId}/files
GET /{userId}/files/file1
GET /{userId}/files/dir1
# create or update file
PUT /{userId}/files/file2
ファイルコンテンツをアップロードするときは、 マルチパートコンテンツタイプ を使用します。
アップロードペイロード内に(ファイルコンテンツへの)リンクを導入することにより、ファイルコンテンツとペイロードの分離を設計します。リソース構造が容易になります。
表現「アップロード」リソース:
{
"upload-content" : "http://storage.org/2a34cafa" ,
"metadata" : "{ .... }"
}
リソースアクション:
# upload file resource
POST /files
-> HTTP 201 CREATED
-> target location is shown by HTTP header 'Location: /files/2a34cafa
# /uploads as naming feels a bit more natural as /files
POST /sessions/{sessionId}/uploads
-> HTTP 201 CREATED
-> HTTP header: 'Location: /sessions/{sessionId}/uploads/1
-> also returning payload
# Updating upload (like metadata)
/PUT/sessions/{sessionId}/uploads/1