RESTful API運行時可發現性/ HATEOAS客戶端設計

對於我參與的SaaS創業公司，我在不同平臺上構建了一個REST風格的Web API和幾個客戶端應用程序。我想我已經找到了API，但現在我正在轉向客戶。正如我一直在閱讀有關REST，我看到REST的一個關鍵部分是發現，但似乎有很多爭論什麼發現的兩種不同的解釋之間的真正含義是：RESTful API運行時可發現性/ HATEOAS客戶端設計

開發發現：開發人員將大量的API詳細信息硬編碼到客戶端，例如資源URI，查詢參數，支持的HTTP方法以及他們通過瀏覽文檔並試用API響應發現的其他詳細信息。這種類型的發現恕我直言，需要冷靜的聯繫和API版本問題，並導致客戶端代碼與API的硬耦合。看起來，如果使用一個記錄良好的RPC集合，這並沒有什麼好處。
運行時發現 - （大概只有一個媒體類型與API交易的知識）的客戶端應用程序本身能夠計算出它與外的帶很少或沒有信息需要的一切鏈接可以很熱。但爲了使API非常高效，似乎需要大量用於查詢參數的鏈接模板，這使得帶外信息蠕動回來了。可能還有其他困難，我還沒有想過，因爲我沒有在開發中得到了這一點。但我確實喜歡鬆耦合的想法。

運行時發現似乎是REST的聖盃，但我看到關於如何實現這樣的客戶端的小小討論。幾乎所有我發現的REST源似乎都假定開發人員發現。任何人都知道一些運行時發現資源？最佳實踐？具有真實代碼的示例或庫？我正在爲一個客戶端開發PHP（Zend Framework）。 Objective-C（iOS）。

運行時發現是一個現實的目標，考慮到開發人員社區中現有的工具和知識集？我可以寫我的客戶端以不透明的方式處理所有的URI，但如何最有效地做到這一點是一個問題，尤其是在低帶寬連接上。無論如何，URI只是等式的一部分。運行環境中的鏈接模板怎麼樣？除了提出大量的OPTIONS請求外，如何溝通支持哪些方法？

來源

2012-02-09 curtisdf

只是稍微放在您的OPTIONS參考。您可以使用「允許」標頭在OPTIONS請求之外傳遞允許的資源操作。 Roy Fielding甚至將頭文件視爲一種超文本形式 - 參見[這裏]（http://tech.groups.yahoo.com/group/rest-discuss/message/14432）。 – paulkmoore 2012-05-19 14:37:59

tats一個gr8的問題，關鍵問題給出的適用方法的列表，客戶應該能夠形成常規CRUD操作的URL或將被稱爲「帶外」？說，如果我們也爲CRUD操作提供鏈接，那麼你如何在json中做「形式」？可能是如果你使用應用程序特定的媒體類型，你不需要做「表單」，但是wat是發現媒體類型的標準方式（即json模式），發現模式的過程是否會被視爲「out-of-樂隊「爲客戶？ – redzedi 2012-07-29 08:06:23

xhtml看起來非常好，流暢，但如果你必須做json，我想現在是非常不穩定 – redzedi 2012-07-29 08:07:47

在此視頻中，Jon Moore使用運行時HATEOAS自動發現構建了一個通用客戶端。這是非常令人印象深刻，非常值得關注：

http://oredev.org/oredev2010/2010/sessions/hypermedia-apis.html

來源

2012-02-09 22:07:43

是否可以在某處使用「客戶端」src代碼？我沒有看到任何客戶端代碼，他只是在java示例中使用他的客戶端 – Denny1989 2015-06-26 10:36:51

@ Denny1989我認爲這是源代碼：https：//github.com/cimlabs/hypermedia-client-java – dbank 2016-01-05 17:00:50

你做了你的家庭作業，你到了它的核心：運行時發現是聖盃。不要追逐它。

告訴UDDI運行時發現的悽美的故事：http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

來源

2012-02-09 01:52:03

這絕對是一個難啃的骨頭。在谷歌，我們已經實施了我們的發現服務，我們所有的新API都是針對它們而構建的。 TL; DR版本是我們生成的JSON模式樣規格，我們的客戶可以解析 - 其中許多是動態的。

這樣的結果意味着開發人員可以更輕鬆地進行SDK升級，並且對我們來說更容易/更好的維護。

絕不是完美的解決方案，但我們的許多開發人員似乎都喜歡。

見link更多細節（並確保觀看VID）

來源

2012-02-09 02:19:36 jonathanberi

是否有任何標準爲我們自己的API實現這樣的發現服務？ – 2014-12-21 18:20:40

引人入勝。你所描述的基本上是HATEOAS原理。你問什麼是HATEOAS？閱讀此：http://en.wikipedia.org/wiki/HATEOAS

通俗地說，HATEOAS意味着鏈接跟隨。這種方法將您的客戶從特定的URL中分離出來，並且使您可以靈活地更改您的API而不會破壞任何人。

來源

2012-02-09 06:01:36 Sam

感謝您提醒我關於HATEOAS。這似乎是我想知道如何處理客戶端界面的關鍵字。（男人，我真的不喜歡這個縮寫！）我之前遇到過HATEOAS，我想我內化了它的意思，但是我忘記了在我的搜索中使用這個名字。現在我看到很多資源正在給我提供更好的照片，並且有些人希望這畢竟無法實現。 – curtisdf 2012-02-09 17:14:05

ios示例？你選擇了什麼？在某些時候，你需要知道你在找什麼！所以你需要知道API，所以你需要硬編碼一些東西！ – Vassily 2012-09-27 13:21:11

@curtisdf完全脫離主題，但不是說你真的不喜歡它，應該說你恨 - 它...恨 - OAS ... :)對不起，無法抗拒 – jamiebarrow 2013-02-18 21:00:59

我想HATEOAS重要的一點不在於它是一些聖盃的客戶端，但它隔離URI改變客戶端 - 假設您正在使用已知（或開發者發現的自定義）鏈接關係，這將允許系統知道對象的哪個鏈接是可編輯的表單。重要的一點是使用可識別超媒體的emdia類型（例如HTML，XHTML等）。

來源

2012-12-11 15:32:46 Falkayn

有關基本運行時發現客戶端的另一個示例，請查看HAL Talk Hypermedia API client demo。

基於超文本應用程序語言（XML鏈接+ JSON模式）：http://stateless.co/hal_specification.html

來源

2013-07-25 14:16:33 papercowboy

你寫：

爲了使API非常有效，查詢參數很多鏈接模板似乎是必要的，這使得出的帶外信息爬回去。

如果該鏈接模板在之前請求提供，那麼就沒有了帶外信息。例如，HTML搜索表單使用鏈接模板（/search?q=%@）來生成URL（/search?q=hateoas），但除了如何使用HTML表單和GET以外，客戶端（網絡瀏覽器）不知道任何內容。

來源

2013-08-06 15:03:26

的確沒有任何客戶端代碼，帶外信息 - 客戶端負責使用提供的資源/實例數據擴展uri模板（並且應該知道如何執行此操作） - http://json-schema.org/latest/json-schema-hypermedia。 HTML＃anchor18 – fusi 2016-01-12 14:12:05

在您調用API'RESTful'之前應該滿足的一個要求是應該可以在該API之上編寫一個通用客戶端應用程序。使用通用客戶端，用戶應該能夠訪問所有API的功能。通用客戶端是一種客戶端應用程序，它不會假定任何資源具有超出媒體類型定義的結構的特定結構。例如，Web瀏覽器是知道如何解釋HTML的通用客戶端，包括HTML表單等。

現在，假設我們爲Web商店提供了HTTP/JSON API，並且我們要構建HTML/CSS/JavaScript客戶端，爲我們的客戶提供卓越的用戶體驗。讓客戶成爲通用客戶端應用程序會是一個現實的選擇嗎？不可以。我們希望爲每個特定的數據元素和每個特定的應用程序狀態提供特定的外觀和感覺。我們不希望在API中包含關於這些表示特定信息的所有知識，相反，客戶應該定義外觀和風格，並且API應該只攜帶數據。這意味着客戶端將特定資源元素與特定佈局和用戶交互進行了硬編碼耦合。

這是HATEOAS的結束，因此REST的結束？ 是和不是。

是，因爲如果對API到客戶端，我們硬編碼的知識，我們失去HATEOAS的好處：服務器端更改可能會破壞客戶端。

沒有，原因有二：

作爲「REST風格」是API的一個屬性，而不是客戶端的。只要有可能，理論上是，要構建一個提供API所有功能的通用客戶端，可以將該API稱爲RESTful。客戶不遵守規則的事實不是API的錯。通用客戶端會有糟糕的用戶體驗這一事實不是問題。爲什麼知道它很重要可能有一個通用客戶端，如果我們實際上沒有那個通用客戶端？這使我想到第二個原因：
RESTful API爲客戶提供了選擇他們想要的通用性的選項，即他們希望如何適應服務器端更改。需要提供良好用戶體驗的客戶仍然可以靈活地修改URI更改，更改默認值等等。在沒有用戶交互的情況下完成批量作業的客戶可能會對其他類型的更改具有彈性

如果您對實際例子感興趣，請檢查我的JAREST paper。最後一節是關於HATEOAS。你會發現，在JAREST中，即使是高度交互式和具有視覺吸引力的客戶端，也可以對服務器端更改產生相當的彈性，但不是100％。

來源

2015-11-02 11:15:50

RESTful API運行時可發現性/ HATEOAS客戶端設計

回答

相關問題