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

RESTful API 的工作原理

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

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

GET 檢索資源;

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

POST 創(chuàng)建該資源;和

刪除以將其刪除。

使用 REST，網(wǎng)絡(luò)組件是用戶請求訪問的資源——就像一個實(shí)現(xiàn)細(xì)節(jié)不明確的黑匣子。所有調(diào)用都是無狀態(tài)的;RESTful 服務(wù)在執(zhí)行之間不能保留任何內(nèi)容。

REST API 支持的數(shù)據(jù)格式包括：

應(yīng)用程序/json

應(yīng)用程序/xml

應(yīng)用程序/x-wbe+xml

應(yīng)用程序/x-www-form-urlencoded

多部分/表單數(shù)據(jù)

用途

因?yàn)檎{(diào)用是無狀態(tài)的，REST 在云應(yīng)用程序中很有用。如果出現(xiàn)故障，無狀態(tài)組件可以自由重新部署，并且可以擴(kuò)展以適應(yīng)負(fù)載變化。這是因?yàn)槿魏握埱蠖伎梢灾赶蚪M件的任何實(shí)例;沒有任何東西需要被下一次交易記住。這使得 REST 更適合 Web 使用。RESTful 模型在云服務(wù)中也很有幫助，因?yàn)橥ㄟ^ API 綁定到服務(wù)是控制 URL 解碼方式的問題。云計算和微服務(wù)幾乎肯定會讓 RESTful API 設(shè)計成為未來的規(guī)則。

RESTful API 設(shè)計和架構(gòu)約束

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

使用統(tǒng)一界面 (UI)。資源應(yīng)該可以通過單個 URL 唯一標(biāo)識，并且只有通過使用網(wǎng)絡(luò)協(xié)議的底層方法，例如使用 HTTP 的 DELETE、PUT 和 GET，才能操作資源。

基于客戶端-服務(wù)器的. 客戶端和服務(wù)器之間應(yīng)該有一個清晰的界限。UI 和請求收集問題是客戶的領(lǐng)域。數(shù)據(jù)訪問、工作負(fù)載管理和安全是服務(wù)器的領(lǐng)域。客戶端和服務(wù)器的這種松散耦合使得每個都可以獨(dú)立地開發(fā)和增強(qiáng)。

無狀態(tài)操作。所有客戶端-服務(wù)器操作都應(yīng)該是無狀態(tài)的，并且所需的任何狀態(tài)管理都應(yīng)該在客戶端而不是服務(wù)器上進(jìn)行。

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

分層系統(tǒng)。REST 允許由多層服務(wù)器組成的架構(gòu)。

按需編碼。大多數(shù)情況下，服務(wù)器將以 XML 或JSON的形式發(fā)回資源的靜態(tài)表示。但是，在必要時，服務(wù)器可以向客戶端發(fā)送可執(zhí)行代碼。

常見的 REST API 挑戰(zhàn)

除了設(shè)計和架構(gòu)限制之外，個人還必須面對 REST API 的一些挑戰(zhàn)。一些可能具有挑戰(zhàn)性的概念可能包括：

端點(diǎn)一致性——端點(diǎn)路徑應(yīng)遵循通用的 Web 標(biāo)準(zhǔn)保持一致，這可能難以管理。

API版本控制——端點(diǎn) URL 在內(nèi)部使用或與其他應(yīng)用程序一起使用時不應(yīng)失效。

響應(yīng)時間長且數(shù)據(jù)過多——返回的資源量會隨時間增加，從而增加負(fù)載和響應(yīng)時間。

導(dǎo)航路徑和用戶輸入位置——因?yàn)?REST 使用 URL 路徑作為輸入?yún)?shù)，確定 URL 空間可能具有挑戰(zhàn)性。

安全性——有很多方面需要關(guān)注，包括使用：

HTTPS;

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

驗(yàn)證 URL;

阻止意外的大負(fù)載;

記錄請求;和

調(diào)查失敗。

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

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

API 測試——設(shè)置和運(yùn)行可能是一個漫長的過程。該過程的每個部分都可能很長，也可能具有挑戰(zhàn)性。也可以使用實(shí)用工具 Curl 在命令行中進(jìn)行測試。

可能具有挑戰(zhàn)性的部分測試過程包括：

最初設(shè)定

架構(gòu)更新

測試參數(shù)組合

序列 API 調(diào)用

驗(yàn)證測試參數(shù)

系統(tǒng)集成

定義錯誤代碼和消息。

對于錯誤代碼，更常見的做法是使用標(biāo)準(zhǔn) HTTP 錯誤代碼。這些更經(jīng)常被客戶和開發(fā)人員認(rèn)可。

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

如果大家想了解更多相關(guān)知識，可以關(guān)注一下動力節(jié)點(diǎn)的Java在線學(xué)習(xí)，里面的課程內(nèi)容從入門到精通，細(xì)致全面，很適合沒有基礎(chǔ)的小伙伴學(xué)習(xí)，希望對大家能夠有所幫助。