相信大家對Java Rest是什么已經有所了解，瀏覽器使用的 REST 可以被認為是互聯網的語言。隨著云使用的增加，云消費者正在使用 API 來公開和組織對 Web 服務的訪問。REST 是構建 API 的合理選擇，允許用戶在分布式環境中靈活地連接、管理和交互云服務。RESTful API 被 Amazon、Google、LinkedIn 和 Twitter 等網站使用。

RESTful API 的工作原理

RESTful API 分解事務以創建一系列小模塊。每個模塊處理事務的底層部分。這種模塊化為開發人員提供了很大的靈活性，但是對于開發人員來說，從頭開始設計他們的 REST API可能是一個挑戰。目前有幾家公司提供模型供開發者使用;Amazon S3、云數據管理接口 ( CDMI ) 和OpenStack Swift提供的模型是最受歡迎的。

RESTful API 使用命令來獲取資源。任何給定時間戳的資源狀態稱為資源表示。RESTful API 使用 RFC 2616 協議定義的現有 HTTP 方法，例如：

GET 檢索資源;

PUT 更改或更新資源的狀態，可以是對象、文件或塊;

POST 創建該資源;和

刪除以將其刪除。

使用 REST，網絡組件是用戶請求訪問的資源——就像一個實現細節不明確的黑匣子。所有調用都是無狀態的;RESTful 服務在執行之間不能保留任何內容。

REST API 支持的數據格式包括：

應用程序/json

應用程序/xml

應用程序/x-wbe+xml

應用程序/x-www-form-urlencoded

多部分/表單數據

用途

因為調用是無狀態的，REST 在云應用程序中很有用。如果出現故障，無狀態組件可以自由重新部署，并且可以擴展以適應負載變化。這是因為任何請求都可以指向組件的任何實例;沒有任何東西需要被下一次交易記住。這使得 REST 更適合 Web 使用。RESTful 模型在云服務中也很有幫助，因為通過 API 綁定到服務是控制 URL 解碼方式的問題。云計算和微服務幾乎肯定會讓 RESTful API 設計成為未來的規則。

RESTful API 設計和架構約束

RESTful API 設計由 Roy Fielding 博士在其 2000 年的博士論文中定義。為了成為真正的 RESTful API，Web 服務必須遵守以下六個 REST 架構約束：

使用統一界面 (UI)。資源應該可以通過單個 URL 唯一標識，并且只有通過使用網絡協議的底層方法，例如使用 HTTP 的 DELETE、PUT 和 GET，才能操作資源。

基于客戶端-服務器的. 客戶端和服務器之間應該有一個清晰的界限。UI 和請求收集問題是客戶的領域。數據訪問、工作負載管理和安全是服務器的領域。客戶端和服務器的這種松散耦合使得每個都可以獨立地開發和增強。

無狀態操作。所有客戶端-服務器操作都應該是無狀態的，并且所需的任何狀態管理都應該在客戶端而不是服務器上進行。

RESTful 資源緩存。所有資源都應該允許緩存，除非明確指出緩存是不可能的。

分層系統。REST 允許由多層服務器組成的架構。

按需編碼。大多數情況下，服務器將以 XML 或JSON的形式發回資源的靜態表示。但是，在必要時，服務器可以向客戶端發送可執行代碼。

常見的 REST API 挑戰

除了設計和架構限制之外，個人還必須面對 REST API 的一些挑戰。一些可能具有挑戰性的概念可能包括：

端點一致性——端點路徑應遵循通用的 Web 標準保持一致，這可能難以管理。

API版本控制——端點 URL 在內部使用或與其他應用程序一起使用時不應失效。

響應時間長且數據過多——返回的資源量會隨時間增加，從而增加負載和響應時間。

導航路徑和用戶輸入位置——因為 REST 使用 URL 路徑作為輸入參數，確定 URL 空間可能具有挑戰性。

安全性——有很多方面需要關注，包括使用：

HTTPS;

阻止來自未知 IP 地址和域的訪問;

驗證 URL;

阻止意外的大負載;

記錄請求;和

調查失敗。

身份驗證——使用常見的身份驗證方法，例如 HTTP 基本身份驗證(允許使用 base64 編碼的用戶名：密碼字符串)、API 密鑰、JSON Web 令牌和其他訪問令牌。例如，OAuth 2.0 有利于訪問控制。

請求和數據——請求可能包含比所需更多的數據和元數據，或者可能需要更多請求才能獲取所有數據。可以為此調整 API。

API 測試——設置和運行可能是一個漫長的過程。該過程的每個部分都可能很長，也可能具有挑戰性。也可以使用實用工具 Curl 在命令行中進行測試。

可能具有挑戰性的部分測試過程包括：

最初設定

架構更新

測試參數組合

序列 API 調用

驗證測試參數

系統集成

定義錯誤代碼和消息。

對于錯誤代碼，更常見的做法是使用標準 HTTP 錯誤代碼。這些更經常被客戶和開發人員認可。

除了解析主體或檢查錯誤之外，錯誤處理可能無法區分響應是否成功。

如果大家想了解更多相關知識，可以關注一下動力節點的Java在線學習，里面的課程內容從入門到精通，細致全面，很適合沒有基礎的小伙伴學習，希望對大家能夠有所幫助。