據我所知,有在REST世界上沒有嚴格的規定
權利; REST不關心你用於資源標識符的拼寫。從客戶的角度來看,標識符是不透明的。服務器可以根據自己的判斷將信息編碼到它們中,並用於它自己的專用。
但是一個好的經驗法則是考慮20世紀90年代的網站會是什麼樣子。
您可以點擊一個標有文件夾的鏈接,這會讓您獲得這些文件夾的表示,包括標有「假期」的條目。點擊該鏈接可以獲得另一個表示,其中包括標有「2016日本」的鏈接。點擊那個鏈接會讓你看到這個,等等。
鏈接的HREF屬性中的值可以是任何內容,因爲您只需單擊它們即可。
"folders" : { "href" : "/28484a30-ccf7-4b36-8f1b-cea70223d4f7" }
"vacations" : { "href" : "/2abaac1b-5bb8-4284-abb6-37953cac68b1" }
"2016 Japan" : { "href" : "/84dfc3c2-3d04-4b33-9551-cb5a35237de5" }
回到恐龍漫遊網頁時,我們經常在處理靜態的分層網站。使用relative references允許重用URI空間中不同點的表示 - 客戶端可以遵循標準resolution rules來計算預期的標識符。
像
"folders" : { "href" : "/folders" }
"vacations" : { "href" : "/folders/vacations" }
"2016 Japan" : { "href" : "/folders/vacations/2016%20Japan" }
%所以你可能會看到拼寫20因爲標識符中的SP必須percent encoded
背景:我需要保留的文件夾結構用戶點擊了。例如。/vacations/2016 Japan/Tokio在我的服務器/後端進一步處理它。因爲我沒有看到實現這個目標的另一種方式,所以我想聽聽你的選擇。
這有點t。。 REST架構風格使用分層風格。這意味着服務器上沒有會話狀態;客戶端只是發送鏈接。
這意味着,當服務器收到/folders/vacations/2016%20Japan
請求時,它不能知道客戶以前訪問過的/folders
和/folders/vacations
。例如,我可能會跟蹤您通過電子郵件發送給我的鏈接。
注意:這樣構成URI沒有任何問題;服務器可以以任何想要的方式將信息編碼到uri中。你只需要小心你對客戶狀態的假設。
這就是說,如果你不打算層次結構,然後path segments可能不是你最好的選擇
路徑組件包含數據,通常以分層形式
非分層組織數據通常以兩種方式之一處理;或者通過其編碼到query component
"folders" : { "href" : "/?folders" }
"vacations" : { "href" : "/?folders,vacations" }
"2016 Japan" : { "href" : "/?folders,vacations,2016%20Japan" }
,或者通過編碼成
"folders" : { "href" : "/folders" }
"vacations" : { "href" : "/folders,vacations" }
"2016 Japan" : { "href" : "/folders,vacations,2016%20Japan" }
在RESTFul Web Services,紅寶石和Richardson提出了使用punctuation to delimit data at the same level in the hierarchy一個個體路徑段;如果順序是重要的,則爲逗號,否則爲分號。
請注意,您的集合中的數據不需要進入最後一個路徑段。
"folders" : { "href" : "/folders/pages" }
"vacations" : { "href" : "/folders,vacations/pages" }
"2016 Japan" : { "href" : "/folders,vacations,2016%20Japan/pages" }
RFC 6570限定variable expansions;訪問支持level 4 templates的URI模板庫使得這些拼寫更實用。
是的,'2016日本'是ID,我明白你的意思。用戶負責選擇他/她的文件夾結構。所以他們分配的文件夾名稱將是我的REST端點的ID。以Dropbox爲例。 – Magiranu
雖然,使用'/ 2016/Japan'這樣的結構可能更有意義。 –