web-dev-qa-db-ja.com

RESTファイルアップロードの設計

ユーザーができるファイルアップロードサービス用にREST APIを作成する必要があります。

  1. セッションを開く
  2. たくさんのファイルをアップロードする
  3. セッションを閉じる

その後、戻ってきて、前のセッションでアップロードしたファイルを使用して処理を行います。

各ファイルに関するデータの処理とファイル自体のコンテンツの処理を容易にするために、これは私が使用することを考えている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する必要があります。

これは理にかなっていますか？そうでない場合、なぜ、どのように改善することができますか？

restfile-uploadapi-design
55
cdeszaq

なぜセッションが必要なのですか？認証と承認の理由ですか？その場合、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
15
manuel aldana