關於REST：WADL或不IDL，以下方法是否正確？

Question

這個問題有點長，請耐心等待。 在REST中，我認爲我們不應該需要WADL或任何IDL。而是隱含地涵蓋其概念的東西。我想到的方式是當我們（人類）在網上衝浪時，當我們第一次去一個網站時，我們不知道它提供了什麼服務。你發現那些在html首頁（或幫助部分的網站地圖頁面）或者可能只是主頁上的主菜單。如果您打個比方，那麼WSDL就是WS-*或者WADL可以用於REST服務的主頁或站點地圖。只有它就像任何其他的HTML內容一樣。 我認爲在REST中，遵循HATEOS範式是一種很好的方式來做事情。擁有列出您的其他資源鏈接的頂級（或默認）資源。對於庫的例子，說RestLibrary.com/它可能是這樣的：

<root xmlns:lib="http://librarystandards.com/libraryml"> 
<resource class="lib:book"> 
    <link type="application/vnd.libraryml+xml" template="mylib.com/book/{isbn}" /> 
    <link type="application/vnd.libraryml+xml" rel="add" href="mylib.com/book" method="POST" /> 
    <link type="application/vnd.libraryml+xml" rel="update" template="mylib.com/book/{isbn}" method="PUT" /> 
</resource> 
<resource class="lib:bookList"> 
    <link template="mylib.com/book?keywords={keywords}" type="application/vnd.openlibrary+xml" rel="search" /> 
</resource> 
</root> 

注意，假設媒體類型「application/vnd.libraryml + XML」是一個定義的標準或（可能只是專有詞彙）名爲libraryml。另外，客戶應該能夠理解這個「主頁」資源（元素根，資源和鏈接）。這是可以用來代替WADL的部分：任何客戶都應該理解的抽象詞彙。您可以使用Atom等現有標準。但主要想法是讓任何客戶都能理解抽象詞彙。那麼爲什麼不WADL？ well wadl僅用於服務發現。這裏的想法是要有一個可以作爲超媒體基礎的輕量級抽象詞彙。一個「根」詞彙。像貓頭鷹一樣，我們有貓頭鷹：東西...... etc 現在，如果客戶端知道「libraryml」標準，它可以遵循它理解的事情的鏈接（解析媒體類型屬性和xmlns之後）。如果不是，它就不會。

當我無法理解如何處理REST架構中的某些東西時，我傾向於看到我們人類在Web中如何做。在Web中，我們擁有通用語言，即HTML，它使站點構建者能夠提供任何特定的內容，而不管其對客戶端（用戶）的意義，瀏覽器理解HTML但不理解其內容的「含義」。用戶理解（域特定）內容。如果我去說QuantumPhysics.org，我的瀏覽器可以呈現主頁（畢竟它只是HTML），我可以閱讀主頁。如果我瞭解量子，那麼我可以繼續瀏覽。如果我不讓我出去（除非我想了解在Hardway :)）

• 在RetsLibrary.com例如 客戶端應用程序就像我+對QuantumPhysics.org我的瀏覽器
• 。媒體類型 「application/vnd.libraryml + xml」是 量子物理（知識）。
• 在這兩個示例中，http都是http。 QuantumPhysics.org的
• 現在，HTML是 RestLibrary.com是XML +那個小 有點抽象詞彙（根 資源和鏈接，你可以用 像原子取代）。

那麼這種方法有什麼價值？我們不需要超級詞彙根本的超級詞彙，所以我們可以通過超媒體和「初始URI」概念獲得成功嗎？

編輯 是啊爲什麼不把RDF當作詞根！

Answer 1

是的，我絕對看到這種媒體類型的需要。

我們都在談論的東西就在freenode IRC休息信這個確切類型的一天後麥克·凱利提出了「超媒體應用程序語言」應用程序/ HAL + XML

爲例見http://restafari.blogspot.com/2010/06/please-accept-applicationhalxml.html的需要。

對於這種類型的事情，RDF似乎有些過分，但我很樂意被證明是錯誤的。我發現RDF比HATEOAS更關注關聯數據。