RestfulApi筆記

RestfulApi筆記

[toc]

簡介

REST即Representational State Transfer的縮寫，可譯爲"表現層狀態轉化」。

• REST最大的幾個特色爲：

  • 資源
  • 統一接口
  • URI
  • 無狀態

特色深刻介紹

• 資源：

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

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

• 統一接口

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

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

---

• URI

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

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

• 無狀態

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

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的主導。

• 區別以下：

本真REST與hybrid風格

一般開發者作服務相關的客戶端開發時，使用的所謂RESTful服務，基本可分爲本真REST和hybrid風格兩類。本真REST即我上文闡述的RESTful架構風格，具備上述的4個特色，是真正意義上的RESTful風格；而hybrid風格，只是借鑑了RESTful的一些優勢，具備一部分RESTful的特色，但對外依然宣稱是RESTful風格的服務。（竊覺得，正是因爲hybrid風格服務混淆了RESTful的概念，纔在RESTful架構風格提出了本真REST的概念，覺得了劃分界限）

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

所以，開發RESTful 服務，若是沒有歷史包袱，不建議使用hybrid風格。

認證

因爲RESTful風格的服務是無狀態的，認證機制尤其重要。例如上文提到的員工工資，這應該是一個隱私資源，只有員工本人或其餘少數有權限的人有資格看到，若是不經過權限認證機制對資源作一層限制，那麼全部資源都以公開方式暴露出來，這是不合理的，也是很危險的。

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

• Basic Auth

簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供用戶名密碼便可，但因爲有把用戶名密碼暴露給第三方客戶端的風險，在生產環境下被使用的愈來愈少。所以，在開發對外開放的RESTful API時，儘可能避免採用Basic Auth.

• Token Auth

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

• OAuth

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

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

正是因爲OAUTH的嚴謹性和安全性，如今OAUTH已成爲RESTful架構風格中最經常使用的認證機制，和RESTful架構風格一塊兒，成爲企業級服務的標配。

目前OAuth已經從OAuth1.0發展到OAuth2.0，但這兩者並不是平滑過渡升級，OAuth2.0在保證安全性的前提下大大減小了客戶端開發的複雜性，所以，Gevin建議在實戰應用中採用OAuth2.0認證機制。

參考博客

oct blog