鏈接標籤的rel-attribute的哪些值應該用於表示集合和文檔的層次結構？

我想代表超文本文件夾中子文件夾和文檔的鏈接（可能使用HAL）。因此，表示文件夾的文檔應該鏈接到文件夾中包含的父文件夾，子文件夾和文件。對於父文件夾，<鏈接rel =「up」href =「..」>似乎是直截了當的選擇。但是，我不確定什麼是最適合鏈接到文件夾中包含的子文件夾和文檔的鏈接。在RFC-5988中定義了幾個選項。但是，我不能說哪一個代表文件夾和文件樹最合適。鏈接標籤的rel-attribute的哪些值應該用於表示集合和文檔的層次結構？

我可以拿出我自己的價值觀和生產文件。例如（使用HTML語法，而隨後的HAL熟悉）：

... 
<link rel="self" href="http://example.com/some/folder/"> 
<link rel="up" href="http://example.com/some/"> 
<link rel="file" href="image1.jpg"> 
<link rel="file" href="image2.png"> 
<link rel="folder" href="subfolder/"> 
...

使用自定義版本的屬性具有的應用程序消耗這些文件需要有他們明確支持的明顯的缺點。因此，我寧願通過遵循標準和最佳實踐來使用應用程序可以理解的內容。

更新： AtomPub（RFC 5023））似乎在集合的成員的鏈接上使用rel =「edit」。我相信他們對於sub.collection沒有一個概念。 RFC-5988的rel =「subsection」可能是一個選項。

來源

2012-10-12 VoidPointer

'rel'屬性用於表示文檔之間的*語義*關係，而不是它們在文件系統上的組織。如果沒有現有的值適用，則不要使用任何值。該屬性不是強制性的。 – Quentin

我會爭辯說，作爲一個集合中的某個項目或某個子集合的東西，可能包含更多項目的語義關係是值得在超文本應用程序中表達的關係。 – VoidPointer

到目前爲止，使用「小節」子集合和「項目」的文件似乎是一個合理的方法......任何想法？ – VoidPointer

代表代表層次結構中的層次
一種非常常見的方式是分級利用水平之間的父子關係的概念。這使您可以非常一般地描述層次結構，而無需將自己綁定到代表文件夾和文檔的，因爲親子/兒童可以代表任何層次結構。例如，DOM解析器大量使用這個概念，因爲DOM是一個層次結構。你需要知道你所處的是什麼類型的「節點」，一個集合（文件夾（文件夾），一個文件夾）或一片葉子（文件）。通過收集與葉子，父母與孩子/孩子的概念，您將能夠輕鬆地指出您應該需要的所有鏈接的關係。

內容類型
任何REST相互作用的最重要的部分是內容類型的在客戶端和服務器的明確的定義。內容類型相對於他們實際需要的內容而言是比較模糊的，但出於您的目的，它可能只是表示一般資源「格式」是HAL，並且還會定義rel值的含義。

大多數人忘記了內容類型是人類。只有內容類型的名稱與用戶代理有關，而不是內容類型定義的內容。內容類型定義由開發人員（或智能用戶代理）使用，以決定如何解釋事物。用戶代理只使用名稱來切換解釋模式。

標準並不能代表一切
一般情況下，您的應用程序代表它自己資源的方式您的應用程序需要比你試圖鞋拔子您表示（S）到一些它更重要「標準」。如果您的應用程序使用up,folder和file最有意義，則通過所有方式使用這些鏈接關係。唯一謹慎的是，我會讓它認真思考如何改變事情。改變一個API並不是最簡單的事情，但是引入一個新的內容類型並且棄用一個較舊的內容類型並不難。

不要誤解我的意思，我都是爲了標準，但是它們本質上幾乎是落後於現實世界的。例如，RCF似乎並沒有很好地處理通用的分層收集。

來源

2012-10-31 13:05:17 cdeszaq

鏈接標籤的rel-attribute的哪些值應該用於表示集合和文檔的層次結構？

回答

相關問題