REST API設計風格都有哪些

REST API設計風格都有哪些，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

　　如果你研究了應用程序中當前定義的所有路由，會注意到其中的幾個符合我上面使用的API的定義。找到它們了嗎？我說的是返回JSON的幾條路由，比如第十四章中定義的/translate路由。這種路由的內容都以JSON格式編碼，并在請求時使用POST方法。此請求的響應也是JSON格式，服務器僅返回所請求的信息，客戶端負責將此信息呈現給用戶。

　　雖然應用程序中的JSON路由具有API的“感覺”，但它們的設計初衷是為支持在瀏覽器中運行的Web應用程序。設想一下，如果智能手機APP想要使用這些路由，它將無法使用，因為這需要用戶登錄，而登錄只能通過HTML表單進行。在本章中，我將展示如何構建不依賴于Web瀏覽器的API，并且不會假設連接到它們的客戶端的類型。

分層系統

　　分層系統原則是說當客戶端需要與服務器通信時，它可能最終連接到代理服務器而不是實際的服務器。因此，對于客戶端來說，如果不直接連接到服務器，它發送請求的方式應該沒有什么區別，事實上，它甚至可能不知道它是否連接到目標服務器。同樣，這個原則規定服務器兼容直接接收來自代理服務器的請求，所以它絕不能假設連接的另一端一定是客戶端。

　　這是REST的一個重要特性，因為能夠添加中間節點的這個特性，允許應用程序架構師使用負載均衡器，緩存，代理服務器等來設計滿足大量請求的大型復雜網絡。

按需獲取客戶端代碼（CodeOnDemand）

　　這是一項可選要求，規定服務器可以提供可執行代碼以響應客戶端，這樣一來，就可以從服務器上獲取客戶端的新功能。因為這個原則需要服務器和客戶端之間就客戶端能夠運行的可執行代碼類型達成一致，所以這在API中很少使用。你可能會認為服務器可能會返回JavaScript代碼以供Web瀏覽器客戶端執行，但REST并非專門針對Web瀏覽器客戶端而設計。例如，如果客戶端是iOS或Android設備，執行JavaScript可能會帶來一些復雜情況。

統一接口

　　最后，最重要的，最有爭議的，最含糊不清的REST原則是統一接口。Dr.Fielding列舉了REST統一接口的四個特性：唯一資源標識符，資源表示，自描述性消息和超媒體。

　　唯一資源標識符是通過為每個資源分配唯一的URL來實現的。例如，與給定用戶關聯的URL可以是/api/users/，其中是在數據庫表主鍵中分配給用戶的標識符。大多數API都能很好地實現這一點。

　　資源表示的使用意味著當服務器和客戶端交換關于資源的信息時，他們必須使用商定的格式。對于大多數現代API，JSON格式用于構建資源表示。API可以選擇支持多種資源表示格式，并且在這種情況下，HTTP協議中的內容協商選項是客戶端和服務器確認格式的機制。

　　自描述性消息意味著在客戶端和服務器之間交換的請求和響應必須包含對方需要的所有信息。作為一個典型的例子，HTTP請求方法用于指示客戶端希望服務器執行的操作。GET請求表示客戶想要檢索資源信息，POST請求表示客戶想要創建新資源，PUT或PATCH請求定義對現有資源的修改，DELETE表示刪除資源的請求。目標資源被指定為請求的URL，并在HTTP頭，URL的查詢字符串部分或請求主體中提供附加信息。

　　超媒體需求是最具爭議性的，而且很少有API實現，而那些實現它的API很少以滿足REST純粹主義者的方式進行。由于應用程序中的資源都是相互關聯的，因此此要求會要求將這些關系包含在資源表示中，以便客戶端可以通過遍歷關系來發現新資源，這幾乎與你在Web應用程序中通過點擊從一個頁面到另一個頁面的鏈接來發現新頁面的方式相同。理想情況下，客戶端可以輸入一個API，而不需要任何有關其中的資源的信息，就可以簡單地通過超媒體鏈接來了解它們。但是，與HTML和XML不同，通常用于API中資源表示的JSON格式沒有定義包含鏈接的標準方式，因此你不得不使用自定義結構，或者類似JSON-API，HAL，JSON-LD這樣的試圖解決這種差距的JSON擴展之一。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。