RESTful API 介紹

API（Application Programming Interface，應用程序編程接口）是一些預先定義的函數或者接口，目的是提供應用程序與開發人員基于某軟件或硬件得以訪問一組例程的能力，而又無須訪問源碼，或理解內部工作機制的細節。

要實現一個 API 服務器，首先要考慮兩個方面：API 風格和媒體類型。

Go 語言中常用的 API 風格是 RPC 和 REST，常用的媒體類型是 JSON、XML 和 Protobuf。

在 Go API 開發中常用的組合是 gRPC + Protobuf 和 REST + JSON。

REST 簡介

REST 代表表現層狀態轉移（REpresentational State Transfer），由 Roy Fielding 在他的 論文 中提出。REST 是一種軟件架構風格，不是技術框架，REST 有一系列規范，滿足這些規范的 API 均可稱為 RESTful API。REST 規范中有如下幾個核心：

REST 中一切實體都被抽象成資源，每個資源有一個唯一的標識 —— URI，所有的行為都應該是在資源上的 CRUD 操作

使用標準的方法來更改資源的狀態，常見的操作有：資源的增刪改查操作

無狀態：這里的無狀態是指每個 RESTful API 請求都包含了所有足夠完成本次操作的信息，服務器端無須保持 Session

無狀態對于服務端的彈性擴容是很重要的。

REST 風格雖然適用于很多傳輸協議，但在實際開發中，REST 由于天生和 HTTP 協議相輔相成，因此 HTTP 協議已經成了實現 RESTful API 事實上的標準。在 HTTP 協議中通過 POST、DELETE、PUT、GET 方法來對應 REST 資源的增、刪、改、查操作，具體的對應關系如下：

HTTP 方法行為URI示例說明

GET	獲取資源列表	/users	獲取賬號列表
GET	獲取一個具體的資源	/users/admin	獲取 admin 賬號的詳細信息
POST	創建一個新的資源	/users	創建一個新賬號
PUT	以整體的方式更新一個資源	/users/1	更新 id 為 1 的賬號
DELETE	刪除服務器上的一個資源	/users/1	刪除 id 為 1 的賬號

RPC 簡介

根據維基百科的定義：遠程過程調用（Remote Procedure Call，RPC）是一個計算機通信協議。該協議允許運行于一臺計算機的程序調用另一臺計算機的子程序，而程序員無須額外地為這個交互作用編程。

通俗來講，就是服務端實現了一個函數，客戶端使用 RPC 框架提供的接口，調用這個函數的實現，并獲取返回值。RPC 屏蔽了底層的網絡通信細節，使得開發人員無須關注網絡編程的細節，而將更多的時間和精力放在業務邏輯本身的實現上，從而提高開發效率。

RPC 的調用過程如下（圖片來自 How RPC Works)：

Client 通過本地調用，調用 Client Stub

Client Stub 將參數打包（也叫 Marshalling）成一個消息，然后發送這個消息

Client 所在的 OS 將消息發送給 Server

Server 端接收到消息后，將消息傳遞給 Server Stub

Server Stub 將消息解包（也叫 Unmarshalling）得到參數

Server Stub 調用服務端的子程序（函數），處理完后，將最終結果按照相反的步驟返回給 Client

Stub 負責調用參數和返回值的流化（serialization）、參數的打包解包，以及負責網絡層的通信。Client 端一般叫 Stub，Server 端一般叫 Skeleton。

REST vs RPC

在做 API 服務器開發時，很多人都會遇到這個問題 —— 選擇 REST 還是 RPC。RPC 相比 REST 的優點主要有 3 點：

RPC+Protobuf 采用的是 TCP 做傳輸協議，REST 直接使用 HTTP 做應用層協議，這種區別導致 REST 在調用性能上會比 RPC+Protobuf 低

RPC 不像 REST 那樣，每一個操作都要抽象成對資源的增刪改查，在實際開發中，有很多操作很難抽象成資源，比如登錄操作。所以在實際開發中并不能嚴格按照 REST 規范來寫 API，RPC 就不存在這個問題

RPC 屏蔽網絡細節、易用，和本地調用類似

這里的易用指的是調用方式上的易用性。在做 RPC 開發時，開發過程很煩瑣，需要先寫一個 DSL 描述文件，然后用代碼生成器生成各種語言代碼，當描述文件有更改時，必須重新定義和編譯，維護性差。

但是 REST 相較 RPC 也有很多優勢：

輕量級，簡單易用，維護性和擴展性都比較好

REST 相對更規范，更標準，更通用，無論哪種語言都支持 HTTP 協議，可以對接外部很多系統，只要滿足 HTTP 調用即可，更適合對外，RPC 會有語言限制，不同語言的 RPC 調用起來很麻煩

JSON 格式可讀性更強，開發調試都很方便

在開發過程中，如果嚴格按照 REST 規范來寫 API，API 看起來更清晰，更容易被大家理解

在實際開發中，嚴格按照 REST 規范來寫很難，只能盡可能 RESTful 化。

其實業界普遍采用的做法是，內部系統之間調用用 RPC，對外用 REST，因為內部系統之間可能調用很頻繁，需要 RPC 的高性能支撐。對外用 REST 更易理解，更通用些。當然以現有的服務器性能，如果兩個系統間調用不是特別頻繁，對性能要求不是非常高，以筆者的開發經驗來看，REST 的性能完全可以滿足。

本教程不是討論微服務，所以不存在微服務之間的高頻調用場景，此外 REST 在實際開發中，能夠滿足絕大部分的需求場景，所以 RPC 的性能優勢可以忽略，相反基于 REST 的其他優勢，筆者更傾向于用 REST 來構建 API 服務器，本教程正是用 REST 風格來構建 API 的。

媒體類型選擇

媒體類型是獨立于平臺的類型，設計用于分布式系統間的通信，媒體類型用于傳遞信息，一個正式的規范定義了這些信息應該如何表示。HTTP 的 REST 能夠提供多種不同的響應形式，常見的是 XML 和 JSON。

JSON 無論從形式上還是使用方法上都更簡單。相比 XML，JSON 的內容更加緊湊，數據展現形式直觀易懂，開發測試都非常方便，所以在媒體類型選擇上，選擇了 JSON 格式，這也是很多大公司所采用的格式。

小結

本小節介紹了軟件架構中 API 的實現方式，并簡單介紹了相應的技術，通過對比，得出本教程所采用的實現方式：API 風格采用 REST，媒體類型選擇 JSON。

通過本小節的學習，讀者可以了解教程所構建 API 服務器核心技術的選型和原因。

本系列文章轉載自公眾號：騰訊游戲存儲與計算技術 微信號: game_infra

總結

以上是生活随笔為你收集整理的【Go API 开发实战 2】RESTful API 介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。