端到端的超媒體REST API設計

Jimmy Bogard 在他的一系列 博客帖子 中表示：REST是一種 定義良好 的架構風格，它能夠為我們帶來許多益處，但也經常被誤用于描述各種各樣的Web API。他特別著重描述了實現一個從服務器到客戶端的端到端超媒體解決方案所必需的步驟，包括如何選擇一種富超媒體的 媒體類型 （media type）。

Bogard是一位 微軟的MVP ，他強調說，REST以及超媒體這種REST的約束會大大提高客戶端與服務端API設計的復雜性。他認為只有在某些場景中才值得這么做，尤其是在客戶端與服務端分別獨立進行設計的情況下。如果客戶端與服務端代碼共存于一個源代碼控制庫，并且還是同時進行部署的，那么超媒體在這種情況下為他提供不了多少價值。

至于如何選擇一種媒體類型，Bogard認為有這么三種選擇：

• 選擇某個現有標準。
• 對某個現有標準進行擴展。
• 設計屬于自己的媒體類型。

考慮到設計一種媒體類型所需的精力，這已遠不是在一個項目中就能夠完成的工作了，因此他傾向于盡可能選擇一種標準的媒體類型。在對不同的媒體類型的能力進行比較時，他提到了 Mike Amundsen 所設計的 H Factor ，這項工具能夠衡量某個媒體類型對于超媒體的支持等級，幫助他做出適合于當前場景的最佳選擇。不過，他往往發現所選擇的媒體類型無法滿足他的所有需求，因此不得不對所缺失的部分進行擴展。

Bogard認為服務端的設計與實現是非常直觀的，這與創建一個純粹的JSON API差別不大，只是增加了一個更豐富的超媒體模型的復雜性。通常來說，包含所選擇的媒體類型的API在實現之后還要接受調用者的檢驗，從客戶端的角度對其進行驗收。

至于客戶端方面，Bogard在文中提到，他所見到的大多數REST示例雖然包含了服務端的API，但往往未能提供實際的實例，使客戶端了解如何調用它們。在Bogard的示例中，他創建了一個web客戶端，其中包含了一個基本的導航視圖。 視圖中包括了一些信息表，用戶可通過這些信息配合在服務端響應中所包含的關系與鏈接查看詳細的內容。服務端返回的響應中包括了大量的元數據，為了保持 REST風格所提供的松耦合能力，客戶端必須由這些元數據所驅動。但Bogard依然認為，客戶端應當為某個特定的目的而設計，要打造一個泛用目的的客戶端是非常無趣的。除了使用jQuery設計客戶端之外，他還描述了如何使用 React 設計并實現客戶端，由于React帶有面向組件的特性，因此在Bogard看來，它能夠非常完美地配合超媒體的使用。

查看英文原文： Design of a Hypermedia REST API Server and Consuming Client