2011-11-28 52 views
4

我有一個Java組件掃描一組文件夾(輸入/處理/輸出)並返回JSON格式的文件列表。設計適當的REST URI

其餘網址同樣是:

GET http://<baseurl>/files/<foldername> 

現在,我需要在每個文件執行特定操作,如驗證,工藝,刪除等我不知道的最好的爲這些操作設計REST URL的方法。 由於它的直接文件操作,我沒有任何文件的唯一標識符,除了它們的路徑。所以,我不知道如果下面是一個很好的網址:

POST http://<baseurl>/file/validate?path=<filepath> 

編輯:我會非常喜歡使用像/文件/ FILEID /驗證。但唯一唯一的文件id是它的路徑,我不認爲我可以將它用作URL本身的一部分。

最後,我不確定哪個HTTP動詞用於像驗證這樣的自定義動作。

在此先感謝!

問候, 阿南德

回答

2

當你實現像http:///file/validate?path路由你編碼在資源行動建模的資源服務時,這不是一個理想的效果。

你可以做以下的讀操作

GET http://api.example.com/files將返回所有文件作爲參考網址如

http://api.example.com/files/path/to/first 
http://api.example.com/files/path/to/second 
... 

GET http://api.example.com/files/path/to/first將返回驗證結果的文件(我使用JSON的可讀性)

{ 
    name : first, 
    valid : true 
} 

這是簡單的閱讀一部分。現在到了寫操作

DELETE http://api.example.com/files/path/to/first當然會刪除該文件

建模文件處理是最困難的部分。但是你可以將它建模爲頂級資源。因此:

POST http://api.example.com/FileOperation?operation=somethingweird將創建一個虛擬文件處理資源並執行由URL參數'operation'給出的操作。將這些文件操作建模爲資源使您可以執行異步操作並返回結果,以提供有關操作過程等的附加信息。

您可以查看Amazon S3 REST API以獲取有關如何爲資源建模的其他示例和靈感。我強烈建議閱讀RESTful Web Services

1

現在,我需要在每個文件執行特定操作,如驗證,工藝,刪除等我不知道來設計REST網址的最佳途徑爲這些行動。由於它的直接文件操作,我沒有任何唯一的文件標識,除了它們的路徑。所以我不確定以下是一個好的網址:POST http:///file/validate?path=

不是。 /file/validate不描述資源,它描述了一個動作。這意味着它是功能性的,而不是RESTful。

編輯:我理想上喜歡用/file/fileId/validate之類的東西。但唯一唯一的文件id是它的路徑,我不認爲我可以將它用作URL本身的一部分。

哦,是的,你可以!而你應該這樣做。除最後的validate部分;這不是一種資源,所以不應該成爲路徑的一部分。相反,客戶端應該向文件資源發佈一條消息,要求它驗證自己。幸運的是,POST允許您向文件發送消息並接收一條消息;它非常適合這類事情(除非使用現有的動詞來代替標準HTTP或諸如WebDAV之類的擴展之一)。

最後,我不確定哪個HTTP動詞用於像驗證這樣的自定義動作。

POST,執行的操作由發送到資源的消息的內容決定。自定義「做非標準」操作總是映射到POST,當它們無法映射到GET,PUT或DELETE時。 (唉,聰明的POST不是很容易發現的,所以會導致HATEOAS原理出現問題,但這還是比違反基本的REST原則更好。)

1

REST需要一個統一的接口,在HTTP中意味着限制你自己去GET,PUT ,POST,DELETE,HEAD等

您可以用RESTful方式檢查每個文件的有效性的一種方法是將有效性檢查視爲不是對文件執行的操作,而是將其作爲自己的資源右:

​​

這可能會返回特定約束violat的一個簡單的真/假,或者一個列表離子。該文件ID可能是一個文件名,一個整數文件號碼,URL編碼的路徑,或者未編碼的路徑,如:

GET /file/bob/dir1/dir2/somefile/validity 

另一種方法是,要求無效的文件列表:

GET /file/invalid 

還有一個是防止無效的文件被添加到擺在首位您服務,即當您的服務流程與壞數據PUT請求:

PUT /file/{file-id} 

它拒絕它與HTTP 400(錯誤請求)。 400響應的主體可能包含有關具體錯誤的信息。

更新:要刪除,當然你可以使用標準的HTTP REST動詞文件:

DELETE /file/{file-id} 

要「進程」文件,這是否創建一個上傳新文件(資源)?例如,Flickr會爲您上傳的每個圖片創建幾個不同的圖片文件,每個圖片文件的大小都不相同。在這種情況下,你可以把輸入文件,然後通過GET-ING相應的輸出文件觸發處理:

PUT /file/input/{file-id}  
GET /file/output/{file-id} 

如果處理不是近乎即時的,你可以以異步方式生成的輸出文件:每一次一個新的輸入文件被放入Web服務中,Web服務啓動一個異步活動,最終導致輸出文件被創建。

+0

根據Fielding的說法,你的第一個陳述是不正確的:「REST風格並不意味着限制這套方法是一個理想的目標。[...]特別是,REST鼓勵創建用於模糊操作的新方法,特別是因爲我們不想用普遍的方法來試圖找出一個特定的操作是否適合99.9%的案例或其他組成0.1%的其中一個邏輯。「資料來源:http://xent.com/pipermail/fork/2001-August/003191.html這就是說,我喜歡你自己的有效性的想法作爲一種資源。 – tuespetre

+0

此外,當服務器本身(如Apache)接收到格式錯誤的請求時(而不是應用程序頭腦中的媒體類型變形時),狀態碼400更多。那將是狀態碼422不可處理的實體。 – tuespetre