爲什麼慢WADL攝取？

Question

我一直在研究WADL，想知道爲什麼它沒有被廣泛採用？

隨着REST使用率的增長速度，我感到驚訝的是，更多的開發工作不使用它。

它的設計是否存在根本性缺陷，是否與通常圍繞RESTful Web服務的文化相匹配，還是完全是其他方式？

Answer 1

我認爲WADL沒有獲得普及的主要原因是它可能會使我們在SOAP和WSDL中遇到的所有問題都重新生活起來。對我而言，互操作性方面是Web服務最重要的一個方面。
通過遵循使用純HTTP標準的RESTful方式，您可以獲得「免費」的互操作性。一旦你需要一個文檔來描述這些服務，就會有不同的客戶端框架（或不同的服務器框架）來解釋這個文檔的不同。 一旦不同的框架自動從WADL生成代碼，您將不得不再次處理互操作性問題。

缺乏標準是RESTful方式的弱點和優勢，讓我們給出簡單的方法一個機會。 （即使我們真的很享受自動代碼生成:-)）

Answer 2

「REST實踐：超媒體系統的體系結構」由吉姆·韋伯，薩瓦斯Parastatidis，和伊恩·羅賓遜提到4個擔憂：

1. WADL需要Web應用程序的前期靜態視圖，其中Web使用中介類型和合同鏈接
2. WADL工具可促進客戶端和服務端抽象的緊密耦合。從服務中發佈的資源成爲客戶的域模型。
3. WADL沒有提供與其公佈的資源進行交互排序的線索。
4. WADL通常會複製資源中可用的元數據。

積分1 & 2是動態客戶端綁定與靜態客戶端綁定的參數。在使用WADL時，服務更改時，服務實現者需要注意模式的向後兼容性。沒有WADL，客戶端必須靈活地解釋響應。

第3點涉及工作流程。 WADL沒有記錄應該調用API的順序。如果根據HATEOAS實踐實施服務，則WADL和非WADL服務響應提供通過鏈接進行訂購的線索。

點4假定HEAD和OPTIONS結果可能與WADL定義不一致。在實踐中，這些方法很少被實現或使用。

許多REST實現很快且很髒。僅爲我的使用而實現REST服務很容易。這是我需要創建一個由另一個團隊提供的服務的客戶端，我需要文檔。越正式越好。代碼可讀的文檔，如WADL，將是最好的。

我作爲一個客戶端實現者關注的是：

1. 我如何發現所支持的查詢參數和頭？
2. 如何找到有關請求或響應媒體類型的文檔？即使它是IANA註冊的媒體類型，我仍然需要請求/響應模式。