基於Java的REST架構風格及接口安全性設計的討論

1.REST即表現層狀態傳遞(Representational [,rɛprɪzɛn'teʃnl] State Transfer,簡稱REST)。html

(1)REST名詞解釋:
通俗來說就是資源在網絡中以某種表現形式進行狀態轉移。分解開來:
Resource:所指的不僅是數據,而是數據和表現形式的組合;
Representational:某種表現形式,好比用JSON,XML,JPEG等;
State Transfer:狀態變化。經過HTTP動詞實現。
(2)RESTful API:
REST(表述性狀態轉移)是一組架構約束條件和原則。知足這些約束條件和原則的應用程序或設計就是RESTful。
參考博文:
 
 
2.Java中實現RESTful API的主流框架:
l Jersey
l RESTEasy
l Restlet
l Apache CXF
以上幾個均爲基於JAX-RS的實現,在性能測試中,JBoss的RESTEasy吞吐率最好,SUN的Jersey其次,CXF、Restlet最差。(網評)
 
 
3.知足HATEOAS(超媒體做爲應用狀態的引擎 Hypermedia As The Engine Of Application State)約束的REST實現,使用Spring Data項目中的如下幾個子項目:
(1)spring-data-rest並無真正的實現JAX-RS(Java API for RESTful Web Services)規範。
其中JAX-RS是Oracle的Java EE 6的技術,與Spring開源平臺下的框架有所不一樣。
(2)Spring Data JPA 是 Spring 基於 ORM 框架、JPA 規範的基礎上封裝的一套JPA應用框架,可以使開發者用極簡的代碼便可實現對數據的訪問和操做。
此外,Spring Data還包括包括非關係 數據庫、Map-Reduce 框架、雲數據服務等等;
 
HATEOAS(Hypermedia as the engine of application state)是 REST 架構風格中最複雜的約束,也是構建成熟 REST 服務的核心。REST 成熟度模型把 REST 服務按照成熟度劃分紅 4 個層次:
  • 第一個層次(Level 0)的 Web 服務只是使用 HTTP 做爲傳輸方式,實際上只是遠程方法調用(RPC)的一種具體形式。SOAP 和 XML-RPC 都屬於此類。
  • 第二個層次(Level 1)的 Web 服務引入了資源的概念。每一個資源有對應的標識符和表達。
  • 第三個層次(Level 2)的 Web 服務使用不一樣的 HTTP 方法來進行不一樣的操做,而且使用 HTTP 狀態碼來表示不一樣的結果。如 HTTP GET 方法來獲取資源,HTTP DELETE 方法來刪除資源。
  • 第四個層次(Level 3)的 Web 服務使用 HATEOAS。在資源的表達中包含了連接信息。客戶端能夠根據連接來發現能夠執行的動做。
 
從上述 REST 成熟度模型中能夠看到,使用 HATEOAS 的 REST 服務是成熟度最高的,也是推薦的作法。對於不使用 HATEOAS 的 REST 服務,客戶端和服務器的實現之間是緊密耦合的。客戶端須要根據服務器提供的相關文檔來了解所暴露的資源和對應的操做。當服務器發生了變化時,如修改了資源的 URI,客戶端也須要進行相應的修改。而使用 HATEOAS 的 REST 服務中,客戶端能夠經過服務器提供的資源的表達來 智能地發現能夠執行的操做。當服務器發生了變化時,客戶端並不須要作出修改,由於資源的 URI 和其餘信息都是動態發現的。
 
 
4.接口的安全性設計:
(1)使用HTTPS加密傳輸。
非對稱加密技術:服務端生成一把給服務端本身用的私鑰,一把給客戶端使用的公開的公鑰。原則是隻有私鑰能打開公鑰,公鑰能打開私鑰,其中一種經典的實現叫RSA算法。
  1. 客戶端向服務器索取公鑰 PublicKey;
  2. 服務器將公鑰發給客戶端(這裏沒有保密需求,由於公鑰是向全部人公開的);
  3. 客戶端使用服務器的公鑰 PublicKey 把 Pre-Master-Key 加密成密文,傳送給服務器;
  4. 服務器用私鑰 PrivateKey 解密密文,獲取到客戶端發送的 Pre-Master-Key;
其中的第二步容易出現被中間人攔截僞造公鑰,這又如何解決?
須要服務端給客戶端發送一個證書,上面記載了服務器的域名,公鑰,單位,簽發機關,有效期等。
可是,又如何保障證書的安全?
其中一種防僞手段就是加簽名,只要有權威機構的簽名,就能夠確認證書是真是的。而計算機的數字化簽名也是使用非對稱加密技術,具體再也不詳述。
 
*(2)身份認證:使用JWT(無狀態分佈式受權,支持各種語言) / OAuth 2.0等。
JWT原理圖:
 
 
*(3)權限管理:Apache Shiro(不依賴Web環境)、Spring Security等。
能夠看到:應用代碼直接交互的對象是Subject,也就是說Shiro的對外API核心就是Subject;其每一個API的含義:
Subject:主體,表明了當前「用戶」,這個用戶不必定是一個具體的人,與當前應用交互的任何東西都是Subject,如網絡爬蟲,機器人等;即一個抽象概念;全部Subject都綁定到SecurityManager,與Subject的全部交互都會委託給SecurityManager;能夠把Subject認爲是一個門面;SecurityManager纔是實際的執行者;
SecurityManager:安全管理器;即全部與安全有關的操做都會與SecurityManager交互;且它管理着全部Subject;能夠看出它是Shiro的核心,它負責與後邊介紹的其餘組件進行交互,若是學習過SpringMVC,你能夠把它當作DispatcherServlet前端控制器;
Realm:域,Shiro從從Realm獲取安全數據(如用戶、角色、權限),就是說SecurityManager要驗證用戶身份,那麼它須要從Realm獲取相應的用戶進行比較以肯定用戶身份是否合法;也須要從Realm獲得用戶相應的角色/權限進行驗證用戶是否能進行操做;能夠把Realm當作DataSource,即安全數據源。
(4)安全過濾:包括防止一些SQL注入、XSS、XXE、XSRF漏洞等。
(5)速度限制:限制某段時間內用戶請求次數。
(6)錯誤處理:非法操做記錄和處理。
(7)參數加密:接口參數加密+時效性驗證+私鑰,如:騰訊開放平臺的OpenAPI。
 
 
5.討論與總結:
(1)REST相比於傳統SOAP的優點?
  • 能夠利用緩存Cache來提升響應速度
  • 通信自己的無狀態性可讓不一樣的服務器處理一系列請求中的不一樣請求,提升服務器的擴展性
  • 瀏覽器便可作客戶端,簡化軟件開發的需求
  • 相對於其餘疊加的HTTP協議之上的機制,REST的軟件依賴性更小
  • 不須要額外的資源發現機制
  • 在軟件技術演進中的長期的兼容性更好
 
SOAP並不假定傳輸數據的下層協議,所以必須設計爲能在各類協議上運行。即便絕大多數SOAP是運行在HTTP上,使用URI標識服務,SOAP也僅僅使用POST方法發送請求,用一個惟一的URI標識服務的入口。固然SOAP也有其本身適用的場景,在安全性、原子性事務、消息可靠性方面有本身獨特的優勢。
 
(2)REST設計的核心是什麼?
  1. 資源(Resource)
這個討論有爭議,有人提出REST並非圍繞資源而設計的,而是一種爲」創建十年內不過期的軟件系統架構「而創建的一種架構風格,也有人認爲REST設計是以系統資源爲中心的Web服務,如「最新訪問的10位會員」和「最活躍的10位會員」在數據上可能有重疊或者徹底相同,而因爲他們的表現形式不一樣,因此被歸爲不一樣的資源。
  1. 資源的表現形式(Representation)
好比用JSON,XML,JPEG等;
  1. 狀態轉移(State Transfer)
通常地,GET/POST/PUT/DELETE便可知足。
  1. 統一接口(Uniform Interface)
對資源使用一致的命名規則(naming scheme),使用惟1、全局統一的命名規則的好處,既適用於瀏覽器中的Web應用,也適用於機對機(machine-to-machine,m2m)通訊。
  1. 超文本驅動(Hypertext Driven)
「超媒體做爲應用狀態的引擎(Hypermedia as the engine of application state)」,有時簡寫爲HATEOAS。嚴格地說這個描述的核心是超媒體概念,換句話說:是連接的思想。
應用程序(已經檢索過文檔)如何「跟隨」連接檢索更多的信息。固然,若是使用一個遵照專用命名規範的簡單「id」屬性做爲連接,也是可行的——可是僅限於應用環境以內。使用URI表示連接的優雅之處在於,連接能夠指向由不一樣應用、不一樣服務器甚至位於另外一個大陸上的不一樣公司提供的資源——由於URI命名規範是全球標準,構成Web的全部資源均可以互聯互通。
超媒體原則還有一個更重要的方面——應用「狀態」。簡而言之,實際上服務器端(若是你願意,也能夠叫服務提供者)爲客戶端(服務消費者)提供一組連接,使客戶端能經過連接將應用從一個狀態改變爲另外一個狀態。
對此原則總結以下:任何可能的狀況下,使用連接指引能夠被標識的事物(資源)。
 
(3)REST的應用場景?
 
如騰訊開放平臺REST API導航圖:
相關文章
相關標籤/搜索