這是一個包含多個部分的問題。我剛剛看到一個關於YQL的主要開發者（我的MS程序畢業生）的一個非常有趣的演講。雖然這非常吸引人，但我期待着嘗試一下，但我想知道是否有人知道用於查詢多個Web服務API以使它們看起來無縫的替代框架，YQL的明顯目的是什麼？YQL的替代品
雅虎的策略是創建XML模式定義，將給定Web服務的參數綁定到他們的YQL Open Table查詢參數中，我認爲這非常聰明。是否有任何工具嘗試（也許我很天真）來自動發現REST API中的參數？我知道使用SOAP APIs，因爲有一個已發佈的WSDL，它使自動化更容易，但是還沒有辦法用REST來做到這一點？有人試過嗎？
有人正在嘗試爲REST生成描述語言。最流行的努力是WADL。在這裏有關於WADL的很多問題。這是個好主意嗎？在我看來沒有。
REST不需要超越它已有的超媒體的發現模型，因爲它試圖解決與web服務不同的體系結構層的問題。 Web服務將數據傳遞給應用程序的業務邏輯/域模型。 REST是關於向表示層提供內容和行爲的。
比喻怎麼樣？想想C++中的對象和結構之間的差異。結構只是一些客戶端進程要操縱的簡單數據。這就是Web服務所做的，它返回一塊數據，一個結構。當然也許它做了一堆服務器端處理來產生結果，但最終結果是一堆數據。 REST接口提供一個對象。即它包含數據和可用於操縱該對象的方法。根據定義，如果您瞭解統一界面並瞭解返回的媒體類型，則您已經知道您可以對響應進行哪些操作。發現機制是多餘的。
如果你覺得這很難相信，那就去思考網絡。 Web瀏覽器如何發現網頁？網絡沒有形式化的發現機制，但我們可以通過網絡瀏覽器發現信息世界。
我不同意這個答案，我不認爲REST僅限於將內容（和行爲）提供給「表示層」。我認爲一個壞習慣綁定到REST的行爲。 – ElLocoCocoLoco 2016-02-20 23:59:20
@ElLocoCocoLoco如果你能幫我理解哪些REST約束被「綁定到REST的行爲」所侵犯，以及這些違規的系統負面影響，那麼我可能會理解爲什麼你認爲它是一個「壞習慣」。 – 2016-02-21 19:22:47
你懂法語嗎？ https://fr.wikipedia.org/wiki/Representational_State_Transfer 在提供「行爲」時，我假設您正在討論第6個（可選約束）REST服務的按需代碼。如果是這樣的話，那通常被認爲是不好的做法，因爲「一個國家變得依賴於客戶端而不是與規則2相矛盾的服務器」。如果你正在談論4.3點「回答解釋其性質」，即使在這種情況下，我們需要一些時間一些服務來解釋結果的性質，然後再執行請求本身（適應性/自動發現系統） – ElLocoCocoLoco 2016-02-22 14:39:34
這個小網站http://zachgrav.es/yql/tablesaw/確實可以自動發現REST API中的參數並將其轉換爲YQL兼容表。
有兩種查找信息的方法。你要麼使用100％明確的語言，要麼使用自然語言。像YQL之類的任何東西都註定會失敗，因爲它既不能提供，而且只能在其作者吹捧的示例中運行良好。我的博客是http://zscraper.wordpress.com/2012/05/30/enough-with-crawling-2。我個人的立場是，如果你先做家庭作業，你會得到最準確的結果，即研究目標領域並弄清楚如何明確地查詢它。
要回答你的問題，並給你一個選擇 - 嘗試Bobik。這是通過REST API控制的雲端支持的抓取服務。使用傳統語法（Bobik支持Javascript，JQuery，XPATH和CSS）撰寫您的「查詢」，然後致電Bobik從任何客戶端環境（網頁，移動應用程序或您的服務器）運行它們。
希望這會有所幫助。
網站http://usebobik.com不再存在。我也相信該服務不再可用。 – Ragaar 2013-11-08 14:35:06
由於同一實體可能有許多不同的表示形式，我對REST API的自動發現工具存在懷疑態度。並可以定義它接受的參數。 WADL試圖讓事情變得更好，但我認爲它在水中已經死了，因爲它違背了REST開發人員的簡約思維。好問題。+1 – 2009-09-24 13:45:58