02 facebook卡在創建賬戶(創建了Facebook的扎卡伯克的妻子是誰？)

瀏覽器是最常見和最通用的REST客戶端。好的RESTful API應該能夠使用瀏覽器+HTML完成所有的測試（不需要使用編程語言）。這樣的API還可以很方便地使用各種自動化的Web功能測試、性能測試工具來做測試。Web前端應用（基于瀏覽器的RIA應用、移動App等等）也可以很方便地將多個RESTful API的功能組合起來，建造Mashup類的應用。

這個API中所包含的資源和對于資源的操作，應該是直觀和容易理解的，并且符合HTTP協議的要求。

REST開發又被稱作“面向資源的開發”，這說明對于資源的抽象，是設計RESTful API的核心內容。RESTful API建模的過程與面向對象建模類似，是以名詞為核心的。這些名詞就是資源，任何可命名的抽象概念都可以定義為一個資源。而HTTP協議并不是一種傳輸協議，它實際提供了一個操作資源的統一接口。對于資源的任何操作，都應該映射到HTTP的幾個有限的方法（常用的有GET/POST/PUT/DELETE四個方法，還有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTful API建模的過程，可以看作是具有統一接口約束的面向對象建模過程。

按照HTTP協議的規定，GET方法是安全且冪等的，POST方法是既不安全也不冪等的（可以用來作為所有寫操作的通配方法），PUT、DELETE方法都是不安全但冪等的。將對資源的操作合理映射到這四個方法上面，既不過度使用某個方法（例如過度使用GET方法或POST方法），也不添加過多的操作以至于HTTP的四個方法不夠用。

這個API應該是松耦合的。

RESTful API的設計包括了三個循序漸進、由低到高的層次：資源抽象、統一接口、超文本驅動。正是這三個層次確保了RESTful API的松耦合性。

當設計面向互聯網的API時，松耦合變成了一種“必須有”的強需求。緊耦合的API非常脆弱，一旦公布出去，服務器端和客戶端都無法持續進化。尤其是服務器端，公布出去的接口根本不敢改，改了之后，幾乎所有客戶端應用立即無法正常工作。REST這種架構風格就是緊耦合API的解毒劑，這個話題可以談的很深，這里就不展開了。感興趣的讀者可以參考《REST實戰》。

這個API中所使用的表述格式應該是常見的通用格式

在RESTful API中，對于資源的操作，是通過在服務器端-客戶端之間傳遞資源的表述來間接完成的。資源的表述可以有很多種格式，并且在響應和請求中的資源表述格式也會有所不同。GET/POST響應中的資源表述格式，常見的有HTML、XML、JSON；POST/PUT請求中的資源表述格式，常見的有標準的HTML表單參數、XML、JSON。

這些常見表述格式，處理起來非常容易，有大量的框架和庫提供支持。所以除非有很合理的要求，通常不需要使用自定義的私有格式。

使用HTTP響應狀態代碼來表達各種出錯情況

HTTP響應狀態代碼，是HTTP協議這個統一接口中用來表達出錯情況的標準機制。響應狀態代碼分成兩部分：status 買粉絲de和reason phase。兩部分都是可定制的，也可以使用標準的status 買粉絲de，只定制reason phase。

如果一個所謂的“RESTful API”對于任何請求都返回200 OK響應，在響應的消息體中返回出錯情況信息，這種做法顯然不符合“確保操作語義的可見性”這個REST架構風格的基本要求。

這個API應該對于HTTP緩存是友好的

充分利用好HTTP緩存是RESTful API可伸縮性的根本。HTTP協議是一個分層的架構，從兩端的user agent到origin server之間，可以插入很多中間組件。而在整個HTTP通信鏈條的很多位置，都可以設置緩存。HTTP協議內建有很好的緩存機制，可以分成過期模型和驗證模型兩套緩存機制。如果API設計者完全沒有考慮過如何利用HTTP緩存，那么這個API的可伸縮性會有很多問題。

李建業：首先說明一下，對REST這個概念，我一般把它理解為REST風格的架構，但是現在實踐中最為廣泛認知的是HTTP，而它是REST的一個實現，所以RESTful API也可以不太嚴格的指基于HTTP的API——當然，即使是不嚴格的時候，API本身也應該力求遵循REST架構風格。

我認為，一個RESTful API最重要的一點應該是——“盡可能少的先驗信息”，這一條也同時是我判斷一個好的RESTful API的標準。

比如HTTP動詞，在實踐中，大家可能會常常糾結于有效利用 HTTP 動詞，但這卻并不是特別重要的事情——除非你理解這么做的價值。HTTP 動詞最重要的地方在于它是標準闡明了的行為，也就是說，如果我們的“客戶端”遵循約定，那么就不必要發明新的動詞，也就不必增加“先驗信息”；但是，所謂“先驗信息”，針對的是客戶端——對API來說就是調用者，對于一些企業內部系統，或者一些傳統系統，由于“資源”很穩定，對資源的操作也很穩定，這些系統的“調用客戶端”不是瀏覽器而是另一個系統，此時如果強制對應到HTTP動詞，反而會變成額外的“先驗信息”，這時我就不會太拘泥HTTP動詞，自己制定一套動詞放在參數中也可以接受——只要動詞不變化，這個系統依然是REST風格的。

再比如Response里面的Content-Type，這個有時會被新手忽略，但這其實很重要，因為一般涉及到系統間協同的API，往往不會使用普通的文本，比較常見的是使用json表達復雜結構，而這與通常的缺省理解不同（缺省一般會認為是text/plain和text/買粉絲），所以如果在API中忘記用Content-Type進行區分的話，后續對多種類型的客戶端接入的支持就會變成陷阱（我們多次遇到過這個問題）。而如果一開始就檢查是否增加先驗知識（缺省Content-Type為plain或者允許指定Content-Type），那這一困難就可以避免了。

丁雪豐：首先，應該正確地使用HTTP的統一接口，比如HTTP的動詞，如果不分青紅皂白清一色POST那顯然還有改進的余地；

其次，資源有合適的粒度，可以從三個方面來評判資源的粒度是否合理——網絡的效率、表述的大小以及客戶端使用時的易用程度；

最后，是表述的設計，除了表述的正文內容，還有其中的URI和鏈接，這些都是評判一個RESTful API好壞的標準。

馬鈞：在我看來，一個好的API標準，就是能盡量利用到HTTP協議的特性，將HTTP當成一種轉移協議，而不是傳輸協議。包括但不限于：利用HTTP的各種動詞來明確操作；包含有內容協商，可以根據請求頭提供的參數選擇一個資源最合適的媒體類型、語言、字符集和編碼的表現；使用不同的返回代碼來描述各種狀態。但實際上見到過的很多聲稱RESTful API，包括國內的和國外的，能符合這些條件的并不多。parse.買粉絲提供的API是我見到過的較為不錯的RESTful API，可以作為范例參考。

InfoQ：安全是恒久的話題，對于基于WSDL和SOAP的Web Service，我們有WS-Security這樣的安全規范來指導實現認證、授權、身份管理等安全需求。那么，RESTful API有無成熟可用規范或實現框架呢？如何保證RESTful API的安全性呢？

李錕：保證RESTful API的安全性，主要包括三大方面：

a) 對客戶端做身份認證

b) 對敏感的數據做加密，并且防止篡改

c) 身份認證之后的授權

對客戶端做身份認證，有幾種常見的做法：

在請求中加簽名參數

為每個接入方分配一個密鑰，并且規定一種簽名的計算方法。要求接入方的請求中必須加上簽名參數。這個做法是最簡單的，但是需要確保接入方密鑰的安全保存，另外還要注意防范replay攻擊。其優點是容易理解與實現，缺點是需要承擔安全保存密鑰和定期更新密鑰的負擔，而且不夠靈活，更新密鑰和升級簽名算法很困難。

使用標準的HTTP身份認證機制

HTTP Basic身份認證安全性較低，必須與HTTPS配合使用。HTTP Digest身份認證可以單獨使用，具備中等程度的安全性。

HTTP Digest身份認證機制還支持插入用戶自定義的加密算法，這樣可以進一步提高API的安全性。不過插入自定義加密算法在面向互聯網的API中用的不是很多。

這個做法需要確保接入方“安全域-用戶名-密碼”三元組信息的安全保存，另外還要注意防范replay攻擊。

優點：基于標準，得到了廣泛的支持（大量HTTP服務器端、客戶端庫）。在服務器端做HTTP身份認證的職責可以由Web Server（例如Nginx）、App Server（例如Tomcat）、安全框架（例如Spring Security）來承擔，對應用開發者來說是透明的。HTTP身份認證機制（RFC 2617）非常好地體現了“分離關注點”的設計原則，而且保持了操作語義的可見性。

缺點：這類基于簡單用戶名+密碼機制的安全性不可能高于基于非對稱密鑰的機制（例如數字證書）。

使用OAuth協議做身份認證

OAuth協議適用于為外部應用授權訪問本站資源的情況。其中的加密機制與HTTP Digest身份認證相比，安全性更高。需要注意，OAuth身份認證與HTTP Digest身份認證之間并不是相互取代的關系，它們的適用場景是不同的。OAuth協議更適合于為面向最終用戶維度的API提供授權，例如獲取隸屬于用戶的微博信息等等。如果API并不是面向最終用戶維度的，例如像七牛云存儲這樣的存儲服務，這并非是OAuth協議的典型適用場景。

對敏感的數據做加密，并且防止篡改，常見的做法有：

部署SSL基礎設施（即HTTPS），敏感數據的傳輸全部基于SSL。

僅對部分敏感數據做加密（例如預付費卡的卡號+密碼），并加入某種隨機數作為加密鹽，以防范數據被篡改。

身份認證之后的授權，主要是由應用來控制。通常應該實現某種基于角色+用戶組的授權機制，這方面的框架有不少（例如Spring Security），不過大多數開發團隊還是喜歡自己來實現相關功能。

李建業：我不認為安全是RESTful API需要考慮的問題，事實上我覺得這是兩個正交的問題。當然，如果使用RESTful API來提供認證、授權和身份管理，那也算是雙方有關系，但是這和其它風格的API設計所要考慮的問題似乎沒什么區別，不值得特別注意。

但是在具體設計層面，這兩者的“正交點”上似乎確實有些問題，因為REST是一個推崇狀態無關原則的架構風格，而認證和授權通常基于第三方解決方案，所以往往會出現違背有狀態約束的問題，這個地方我也沒有特別的想法，當然這個困難和原問題關系不大。

至于WS-族的協議，我不太了解，不太能參與討論。

丁雪豐：對于RESTful API，常見的安全措施都是可以繼續使用的。例如，為了防篡改，可以對全部參數進行簽名；為了防范重放攻擊可以在請求中增加一次性的Token，或者短時間內有效的Token；對內容加密可以實現數據防泄露……；對于DDoS攻擊，各種HTTP流量清洗策略，都可以繼續發揮作用，因為這就是基本的HTTP請求。

在授權和認證方面，OAuth 2.0已經基本成熟了，并且得到了廣泛地應用。如

很赞哦!（47）