本文轉載自https://blog.igevin.info/posts/restful-architecture-in-general/

在移動互聯網的大潮下，隨著docker等技術的興起，『微服務』的概念也越來越被大家接受並應用於實踐，日益增多的web service逐漸統一於RESTful 架構風格，如果開發者對RESTful 架構風格不甚了解，則開發出的所謂RESTful API總會貌合神離，不夠規範。

本文是我對RESTful 架構風格的一些理解，和大家分享一下，如果有問題，歡迎討論。
Outline

1. RESTful架構風格
    1.1 RESTful架構風格的特點
        1.1.1 資源
        1.1.2 統一接口
        1.1.3 URI
        1.1.4 無狀態
    1.2 ROA、SOA、REST與RPC
    1.3 本真REST與hybrid風格
2. 認證機制
    2.1 Basic Auth
    2.2 Token Auth
    2.3 OAuth
3. 總結
 

1. RESTful架構風格

RESTful架構風格最初由Roy T. Fielding（HTTP/1.1協議專家組負責人）在其2000年的博士學位論文中提出。HTTP就是該架構風格的一個典型應用。從其誕生之日開始，它就因其可擴展性和簡單性受到越來越多的架構師和開發者們的青睞。一方面，隨著雲計算和移動計算的興起，許多企業願意在互聯網上共享自己的數據、功能；另一方面，在企業中，RESTful API（也稱RESTful Web服務）也逐漸超越SOAP成為實現SOA的重要手段之一。時至今日，RESTful架構風格已成為企業級服務的標配。

REST即Representational State Transfer的縮寫，可譯為"表現層狀態轉化”。REST最大的幾個特點為：資源、統一接口、URI和無狀態。

1.1 RESTful架構風格的特點

1.1.1 資源

所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。資源總要通過某種載體反應其內容，文本可以用txt格式表現，也可以用HTML格式、XML格式表現，甚至可以采用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現；JSON是現在最常用的資源表示格式。

結合我的開發實踐，我對資源和數據理解如下：

資源是以json(或其他Representation)為載體的、面向用戶的一組數據集，資源對信息的表達傾向於概念模型中的數據：

資源總是以某種Representation為載體顯示的，即序列化的信息
常用的Representation是json(推薦)或者xml（不推薦）等
Represntation 是REST架構的表現層
 

相對而言，數據（尤其是數據庫）是一種更加抽象的、對計算機更高效和友好的數據表現形式，更多的存在於邏輯模型中

資源和數據關系如下：

resource vs data

1.1.2 統一接口

RESTful架構風格規定，數據的元操作，即CRUD(create, read, update和delete,即數據的增刪查改)操作，分別對應於HTTP方法：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源，這樣就統一了數據操作的接口，僅通過HTTP方法，就可以完成對數據的所有增刪查改工作。

即：

GET（SELECT）：從服務器取出資源（一項或多項）。
POST（CREATE）：在服務器新建一個資源。
PUT（UPDATE）：在服務器更新資源（客戶端提供完整資源數據）。
PATCH（UPDATE）：在服務器更新資源（客戶端提供需要修改的資源數據）。
DELETE（DELETE）：從服務器刪除資源。

1.1.3 URI

可以用一個URI（統一資源定位符）指向資源，即每個URI都對應一個特定的資源。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或識別符。

一般的，每個資源至少有一個URI與之對應，最典型的URI即URL。

1.1.4 無狀態

所謂無狀態的，即所有的資源，都可以通過URI定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而改變。有狀態和無狀態的區別，舉個簡單的例子說明一下。如查詢員工的工資，如果查詢工資是需要登錄系統，進入查詢工資的頁面，執行相關操作後，獲取工資的多少，則這種情況是有狀態的，因為查詢工資的每一步操作都依賴於前一步操作，只要前置操作不成功，後續操作就無法執行；如果輸入一個url即可得到指定員工的工資，則這種情況是無狀態的，因為獲取工資不依賴於其他資源或狀態，且這種情況下，員工工資是一個資源，由一個url與之對應，可以通過HTTP中的GET方法得到資源，這是典型的RESTful風格。

state

stateless

1.2 ROA、SOA、REST與RPC

ROA即Resource Oriented Architecture，RESTful 架構風格的服務是圍繞資源展開的，是典型的ROA架構（雖然“A”和“架構”存在重復，但說無妨），雖然ROA與SOA並不沖突，甚至把ROA看做SOA的一種也未嘗不可，但由於RPC也是SOA，比較久遠一點點論文、博客或圖書也常把SOA與RPC混在一起討論，因此，RESTful 架構風格的服務通常被稱之為ROA架構，很少提及SOA架構，以便更加顯式的與RPC區分。

RPC風格曾是Web Service的主流，最初是基於XML-RPC協議（一個遠程過程調用（remote procedure call，RPC)的分布式計算協議），後來漸漸被SOAP協議（簡單對象訪問協議（Simple Object Access Protocol））取代；RPC風格的服務，不僅可以用HTTP，還可以用TCP或其他通信協議。但RPC風格的服務，受開發服務采用語言的束縛比較大，如.NET框架中，開發web service的傳統方式是使用WCF，基於WCF開發的服務即RPC風格的服務，使用該服務的客戶端通常要用C#來實現，如果使用python或其他語言，很難實現可以直接與服務通信客戶端；進入移動互聯網時代後，RPC風格的服務很難在移動終端使用，而RESTful風格的服務，由於可以直接以json或xml為載體承載數據，以HTTP方法為統一接口完成數據操作，客戶端的開發不依賴於服務實現的技術，移動終端也可以輕松使用服務，這也加劇了REST取代RPC成為web service的主導。

RPC與RESTful的區別如下面兩個圖所示：

blog-post-REST-vs-RPC1

blog-post-REST-vs-RPC2

1.3 本真REST與hybrid風格

通常開發者做服務相關的客戶端開發時，使用的所謂RESTful服務，基本可分為本真REST和hybrid風格兩類。本真REST即我上文闡述的RESTful架構風格，具有上述的4個特點，是真正意義上的RESTful風格；而hybrid風格，只是借鑒了RESTful的一些優點，具有一部分RESTful的特點，但對外依然宣稱是RESTful風格的服務。（竊以為，正是由於hybrid風格服務混淆了RESTful的概念，才在RESTful架構風格提出了本真REST的概念，以為了劃分界限 :P）

hybrid風格的最主流的用法是，使用GET方法獲取資源，用POST方法實現資源的創建、修改和刪除。hybrid風格之所以存在，據我了解有兩種來源：一種情況是因為，某些開發者並沒有真正理解何為RESTful架構風格，導致開發的服務貌合神離；而主流的原因是由於歷史包袱 —— 服務本來是RPC風格的，由於上文提到的RPC的劣勢及RESTful的優勢，開發者在RPC風格的服務上又包裝了一層RESTful的外殼，通常這層外殼只為獲取資源服務，因此會按RESTful風格實現GET方法，如果客戶端提出一些簡單的創建、修改或刪除數據的需求，則通過HTTP協議中最常用的POST方法實現相應功能。

因此，開發RESTful 服務，如果沒有歷史包袱，不建議使用hybrid風格。

2. 認證機制

stateless-auth

由於RESTful風格的服務是無狀態的，認證機制尤為重要。例如上文提到的員工工資，這應該是一個隱私資源，只有員工本人或其他少數有權限的人有資格看到，如果不通過權限認證機制對資源做一層限制，那麽所有資源都以公開方式暴露出來，這是不合理的，也是很危險的。

認證機制解決的問題是，確定訪問資源的用戶是誰；權限機制解決的問題是，確定用戶是否被許可使用、修改、刪除或創建資源。權限機制通常與服務的業務邏輯綁定，因此權限機制需要在每個系統內部定制，而認證機制基本上是通用的，常用的認證機制包括 session auth(即通過用戶名密碼登錄)，basic auth，token auth和OAuth，服務開發中常用的認證機制為後三者。

2.1 Basic Auth

HTTP Basic authentication (BA) implementation is the simplest technique for enforcing access controls to web resources because it doesn't require cookies, session identifier and login pages. Rather, HTTP Basic authentication uses static, standard fields in the HTTP header which means that no handshakes have to be done in anticipation.

Visit Wikipedia To Read More

簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供用戶名密碼即可，但由於有把用戶名密碼暴露給第三方客戶端的風險，在生產環境下被使用的越來越少。因此，在開發對外開放的RESTful API時，盡量避免采用Basic Auth

2.2 Token Auth

Token Auth並不常用，它與Basic Auth的區別是，不將用戶名和密碼發送給服務器做用戶認證，而是向服務器發送一個事先在服務器端生成的token來做認證。因此Token Auth要求服務器端要具備一套完整的Token創建和管理機制，該機制的實現會增加大量且非必須的服務器端開發工作，也不見得這套機制足夠安全和通用，因此Token Auth用的並不多。

本文不在展開介紹Token Auth，我個人對這套機制也了解有限，有興趣了解這套機制的同學不妨從Stack Overflow上的這篇討論入手。

2.3 OAuth

OAuth is an open standard for authorization. OAuth provides client applications a 'secure delegated access' to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The client then uses the access token to access the protected resources hosted by the resource server. OAuth is commonly used as a way for Internet users to log into third party websites using their Microsoft, Google, Facebook or Twitter accounts without exposing their password.

OAuth is a service that is complementary to and distinct from OpenID. OAuth is also distinct from OATH, which is a reference architecture for authentication, not a standard for authorization. However, OAuth is directly related to OpenID Connect (OIDC) since OIDC is an authentication layer built on top of OAuth 2.0.

Visit Wikipedia To Read More

OAuth（開放授權）是一個開放的授權標準，允許用戶讓第三方應用訪問該用戶在某一web服務上存儲的私密的資源（如照片，視頻，聯系人列表），而無需將用戶名和密碼提供給第三方應用。

OAuth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的第三方系統（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容。

正是由於OAUTH的嚴謹性和安全性，現在OAUTH已成為RESTful架構風格中最常用的認證機制，和RESTful架構風格一起，成為企業級服務的標配。

目前OAuth已經從OAuth1.0發展到OAuth2.0，但這二者並非平滑過渡升級，OAuth2.0在保證安全性的前提下大大減少了客戶端開發的復雜性，因此，Gevin建議在實戰應用中采用OAuth2.0認證機制。

現在網上關於OAuth的資料非常豐富，也有大量開源的第三方庫實現了OAuth機制，不熟悉OAuth的同學從OAuth官網入手即可。

3. 總結

本真REST + OAuth是RESTful 是微服務的標配
Basic Auth只在開發環境中使用
設計合理的資源
用正確的HTTP方法對數據發正確的請求

【轉載】RESTful 架構風格概述