摘要：相信未來REST規范將會變得更加流行和普及，
本文分享自華為云社區《云原生時代，遠程服務呼叫和RESTful，如何分析和抉擇？》，作者：breakDawn ，
隨著云原生的概念越來越火，服務的架構應該如何發展和演進，成為很多程式員關心的話題，大名鼎鼎的《深入理解java虛擬機》一書作者于21年推出了新作《鳳凰架構》，從這本書中可以看到當前時下很多最新的技識訓者理念，
本博文將沉淀發布這本書的學習筆記和思考， 如果希望了解更加詳細的內容，歡迎購買該書繼續詳細學習，
訪問遠程服務
1 遠程服務呼叫
這一個章節主要講解rpc的設計理念和發展歷史，
先是講解了IPC（行程間通信）所需要的各個必要因素
接著解釋RPC 是IPC的一種特例（這是最初科學家們的想法）
但PRC存在很多可靠性的問題，并不能直接等同IPC的擴展，
接著提出了RPC的三個基本問題：
- 如何表示資料
即序列化協議， 有grpc的proto-buffer、json、xml、java-rmi基于java自帶序列化之列的 - 如何傳遞資料
基于什么網路協議傳輸
java-rmi的遠程協議
JSON-RPC協議
SOAP協議（web service 簡單對下訪問） - 如何表示方法
如何定義方法，如何在不同語言、不同系統環境中保證 方法簽名唯一，
需要對介面描述定義語言有一個選型
再后面講解了rpc的發展歷史
CORBA的使用過于復雜，被拋棄
SOAP使用xml很簡單，但是性能奇差
可以看出RPC想同時滿足簡單、普適、高性能是很難的
于是得出一個結論：
不存在完美的RPC框架
最近幾年的RPC框架更傾向于往高層次、插件化發展，
即不再獨立解決RPC的所有問題，而是提供一些擴展點由用戶自己選擇（比如dubbo）
可以任意切換json或者fastjson等序列化方式
可以切換傳輸協議等，
2 REST
rest并不是一種遠程呼叫協議， 他只能說是一種風格，
REST的傳輸效率提升潛力有限，但是可以簡化呼叫，
2.1 REST核心概念（基于HTTP超文本傳輸協議）
- 資源
資源指你希望獲取或者修改的東西、資訊本身，他的表現形式可以不同，但是里子是相同的 - 表征
就是表現資源的形式，用html還是pdf來回傳 - 狀態
指的是服務端對某次會話是否持有狀態，
例如讀下一篇文章時，當前文章id由服務端存盤還是瀏覽器存盤，這就是有狀態和無狀態的區別， - 轉移
就是服務端提供的行為邏輯， 通常叫做 資源的轉移 - 統一介面
就是HTTP協議里提供的GET\HEAD\POST\PUT\DELETE\TRACE\OPTIONS這七種操作，通過這些操作觸發轉移 - 超文本驅動
瀏覽器的行為經常是通過服務端回傳的url或者各種資訊觸發了驅動行為 - 自描述訊息
為了方便客戶端識別表征，回傳類似于Content-Type等內容，方便用何種字符集處理
2.2 REST核心設計原則
- 客戶端與服務端分離
服務端不處理渲染， 由客戶端來處理 - 無狀態
盡可能希望服務端不要存盤rest會話狀態，達到分布式的高價值回報，
但是不太可能特別是客戶端持有會話數量級很大的情況下，所以仍舊會持有一定狀態 - 可快取
服務端的應答中要直接或者間接告知客戶端是否可以快取，快取多久 - 分層系統
客戶端不需要知道是否真的連接到了最終的服務器
代表是CDN內容分發網路 - 統一介面
面向資源編程
系統設計時聚焦在資源而不是行為上
例如面向行為時， 登錄就是login介面，注銷就是logout介面
而面向資源時，登錄就是PUT Session, 注銷就是DELETE Session - 按需代碼
客戶端的代碼可以有一部分讓服務端發回進行裝載，
2.3 REST的好處
- 降低服務介面的學習成本
- 資源天然具有集合與層次介面
這樣很多資源可以很容易組合在一起并讓使用者想到介面url是什么
例如獲取 用戶 icyfenix的購物車中的第2本書，這個是有層次的，那么介面就是GET /user/icyfenix/cart/2 - REST系結于HTTP協議，HTTP又是大家非常熟悉的
2.4 RMM（Richardson提出的restful成熟度模型）
第0級：完全不rest
提供的api定義里總是包含了各種動作，例如
/queryXXX
/applyXXX
類似于RPC的行為介面
壞處是一旦要提供其他對XXX的操作，必須重新撰寫介面，無法對XXX的查詢能力進行復用！
第1級：開始引入資源的概念
api的endpoint定義應該圍繞名詞+資源id而不是動詞來定義，
POST /doctors/mjones 獲取醫生的檔期
POST /schedules/{id} 觸發對這個id的調度
第2級： 引入統一介面，映射到HTTP方法上
上面的method都是POST，實際上可以把HTTP方法的method、回傳碼都給利用上
- 對一個資源的增加用POST，洗掉用DELETE，更新用PUT
- 依賴HTTP的回傳碼定義資源可能的例外情況，例如201代表創建成功，409代表沖突（被人搶先預約）
- 利用HTTP自帶的認證和授權資訊，
第3級：超文本控制，轉移行為通過回應控制
第2級里， 所有介面的定義仍然需要使用者自己查詢檔案來記憶和應用
實際上應該只需要一個操作起始入口， 例如獲取醫生的檔期介面
這個介面要回傳的body里，已經告知了對應資源的名稱，例如檔期資源的key就叫做schedules
那么就能馬上知道下一個介面查詢用schedules了！
這樣代碼里可以做好適配，當你要把檔期的key名做修改時，客戶端代碼根本不用變動！
2.2.4 REST的不足和爭議
1.restful面向資源編程只適合做CRUD，不適合過于復雜的業務邏輯
- 面向程序編程，以演算法和處理程序為中心，這符合計算機世界中主流的互動方式
- 面向物件編程，將資料和物件行為統一起來，因為這符合現實世界的主流互動方式
- 面向資源編程，資料作為主體，行為看成統一介面，為了符合網路世界的主流互動方式
2.rest不利于事務支持
作者不同意這個觀點， 認為不會有阻礙，取決于系統的事務設計
3.rest沒有傳輸可靠性支持
雖然確實沒有類似于重發等機制的保證，但rest介面一般盡可能要求冪等性，來做到應用代碼做重發時可以不用擔心重復的問題
4.缺少對資源做部分或者批量處理的能力
rest語意里不能涵蓋這種情況，得定義特殊的介面或者引數，那么低3級里面就不能涵蓋了，
相關思考
基于REST的規范，呼叫者可以非常快速地理解自己需要的介面內容是什么樣的，例如華為云當前的很多云服務公開介面都會基于REST理念進行開放， 并且各云服務的開放介面都會集成到API Explorer和華為云SDK中心供開發者直接呼叫，這些平臺提供了豐富的介面檔案和示例代碼，幫助開發者更快地上手和使用 REST 介面，
相信未來REST 規范將會變得更加流行和普及，隨著云計算和大資料技術的不斷發展，REST 介面將會被廣泛應用于各種領域，例如醫療、金融、電商等，REST 介面的開放性、可擴展性和易用性，將會為開發者帶來更加高效、便捷和可靠的開發體驗，
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/551296.html
標籤：其他
上一篇：位元組超全學習流程圖流出，100天漲薪10k，從功能測驗到自動化測驗
下一篇：返回列表