REST風格的「複製」方法

我正在研究基於node.js的REST API來管理遠程系統上的文件。要創建一個包含內容的新文件，我正在向請求主體包含文件內容的URI發出一個PUT請求。爲了檢索文件的內容，發出GET請求並且響應主體包含文件內容。REST風格的「複製」方法

但是，我很難確定一種實現複製功能的好方法。我目前唯一有效的方法是發出GET，檢索源文件，然後用PUT請求重新發送內容。

我已經探索過的一個想法是發出一個PUT請求的目標文件，標題中的數據標識要複製數據的源文件。但是，對於那些不太完美的API設計，如果需要的話可以使用。

理想情況下，我希望能夠對目標文件發出PUT請求，並基本上將源文件的GET請求的主體重定向到PUT請求的正文中，而不必將整個文件內容首先下載到客戶端。

我的問題是，有沒有一種有效的/適當的方式，我可以發出一個HTTP/S PUT請求，指定正文內容應該是不同URI的GET請求的主體，而無需首先將它下載到客戶？ API當前bahaviors的

例子：

獲取文件的內容（sourcefile.ext）

GET https://server.com/directory/sourcefile.ext 
# the body of the response if good is the file contents

創建內容（destinationfile.ext）文件

PUT https://server.com/directory/destinationfile.ext 
# the body of the request is the desired file contents

理想的複製功能（的資源文件.ext - > destinationfile.ext）

PUT https://server.com/directory/destinationfile.ext 
# somehow tell the request to pull the body from a GET request to 
# https://server.com/directory/sourcefile.ext 
# being made by the API server rather than the client issuing both requests 
# in succession

可以使用，如果必須的話，我會使用它，但是目前在API的其他地方沒有使用?var1=val1&var2=val2查詢（他們在其他地方不需要），我想保持請求的標準化如果我能幫助它。

來源

2017-06-01 FatalKeystroke

發佈您的代碼，以便可以複製和處理問題 – TheDarkKnight

這不是關於特定代碼的問題。更多的是一種方式來提示HTTP/S協議中某種語言或代碼庫的特定行爲。（加上與此相關的最小工作客戶端和服務器端代碼將遠遠超過適用於有關傳輸協議的問題。） – FatalKeystroke

這是您的API，是否有某些原因您無法提供GET請求，其中參數是現有文件，複製位置？答案是確定的或拒絕訪問或文件不存在或無效的複製名稱。 –

爲什麼限制自己GET和PUT？顯然你可以做一個POST請求來做你想做的事情。您可以將源自身的URL複製到源。您可以使用要從中複製的網址發佈到目標。或者你可以將兩個URL發佈到一個拷貝對象（我知道，不是最好的形式，但也不是非法的）。

只有在涉及單個資源時，GET和PUT才能正常工作。你有兩個資源。涉及多個資源的任何操作都必須使用POST，並且您在使用方式上有很大的自由度。

來源

2017-06-01 05:25:45 AgilePro

唯一需要的功能是「檢索文件」，「創建文件」，「刪除文件」，「檢索文件信息」和「將文件複製到新位置」。目前，使用GET，PUT，DELETE和HEAD分別完成相同的請求格式（當然，複製除外），其中每個請求或響應主體的正文僅僅是文件內容。 POST會工作，但打破模式，因爲身體將是複製內容的信息而不是文件內容。這並不是說它不可能讓它做我想做的事，而是讓它做我想做的事並保持一致的API行爲。 – FatalKeystroke

我與@AgilePro - 你創建一個新文件的PUT應該是一個POST來堅持PUT的REST（和HTTP動詞）原則是[idempotent]（https://stormpath.com/blog/put-or -post＃idempotency）和POST是非冪等的。這使得副本的答案也是POST。兩者都在給定的URI創建新資源，這是POST的目的。 – busse

「一致性爲了一致性」是一個誤導性的目標。當你做的事情相似時，儘可能使命令儘可能相似是有意義的。但是當你有一些根本不同的東西時，讓命令改變是正確和恰當的。強迫兩件事情不完全相同，與現實生活中的APPEAR相同往往會使其更加混亂。雖然避免任意差異的目標是值得讚賞的，但當這種差異是正確的時候，您的API將因使命令不同而受益。「恰當性」>「盲目一致性」 – AgilePro

REST風格的「複製」方法

回答

相關問題