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

果可以，接入第三方賬戶體系是個不錯的選擇，比如Google和Facebook的，國內的當然也有幾個候選。

馬鈞：個人認為RESTful的安全性分為幾個層次，在安全要求較高的場合，可以通過HTTPs這樣的加密協議來保證網絡層的安全，應用層的安全可以通過OAuth實現認證，而對于資源的訪問授權，則只能依靠應用程序來實現了。

InfoQ：如何對RESTful API進行版本控制，請分享您認為實用的做法？

李錕：一個比較簡單實用的做法是直接在URI中插入版本號，這樣做允許多個版本的API并行運行。

另一個做法是在HTTP請求中加入自定義頭信息，標明使用的版本號。不過這個做法其實對瀏覽器不夠友好，簡單地使用瀏覽器+HTML無法測試。

李建業：目前比較好的方式還是在uri設計中添加版本信息，其它方法都不如這個實用。

丁雪豐：個人認為最好的版本化，就是沒有明顯的版本。在對已發布的服務進行變更時，要盡量做到兼容，其中包括URI、鏈接和各種不同的表述的兼容，最關鍵的就是在擴展時不能破壞現有的客戶端。例如，要變更一個參數，可以選擇同時兼容新舊兩種輸入，或者保持老參數不動，提供一個新的參數，在文檔中必須做出說明，不推薦新用戶再繼續使用之前的參數。

如果必須要進行不兼容的變更，那么可以選擇標記不同的版本號，這時可以選擇在路徑或參數中增加版本信息。也有做法是增加HTTP標頭，只是在調用時會稍有不便，推薦前兩種方法。

馬鈞：RESTfulAPI的版本升級，盡量兼容之前的版本，保證原有的API都能正常工作，可以通過HTTP 301轉跳到新的資源。另外一種實用的做法就是在url中保留版本號，同時提供多個版本供客戶端使用，如 v1.rest.買粉絲 或者 rest.買粉絲/v1/ 這樣。

InfoQ：HTTP1.1規范中給出的動詞對于設計RESTful API夠用嗎？您在實際項目中會擴展自己的動詞嗎？在什么情況下需要擴展？

李錕：這個問題取決于設計者如何看待和設計資源。如果資源抽象做的很好，對于某個資源的任何操作，通常都能夠映射到CRUD四個類別中。CRUD四個類別對于操作資源來說，絕大多數情況下是完備的。HTTP的GET/POST/PUT/DELETE四個方法，對于CRUD四個類別的操作來說是足夠的，映射關系是Create-POST/Retrieve-GET/Update-PUT/Delete-DELETE。

李建業：一般是夠用的，有時一些“不夠用”的場景是由于我們沒有設計出合理的資源，比如批量操作。但是，正如之前所說的那樣，對于某些內部的、傳統的（因此模型穩定且已知）系統，API提供者和調用者會有自已的固定動詞表，此時沒必要拘泥。另外，我不建議擴展動詞，一旦擴展了動詞，其實已經破壞了我之前說的*“盡可能少的先驗信息”*，那么，擴展動詞和重新設計動詞的成本差別不大。基于這個考慮，我建議盡可能保持動詞不變，除非你想重新設計動詞表。

丁雪豐：一般情況下，常用的HTTP動詞是夠用的，并沒有出現一定要自己擴展動詞的情況。其實，最常用的也就是GET、POST、DELETE和PUT，而HEAD、OPTIONS、TRACE則基本用不太到。如果出現一時找不到合適的動詞，安全冪等的操作用GET，其他都可以用POST，在設計資源時稍加考慮即可。

馬鈞：在我的實際項目中，只用到了POST，PUT，DELETE，GET這四個動詞。

InfoQ：今年5月份發布的JAX-RS 2.0規范對于RSTfulAPI的設計最有價值的特性是哪個（些）? 它（們）用于解決什么問題？

李錕：REST開發框架RESTEasy項目負責人Bill Burke，去年寫了一篇文章介紹JAX-RS 2.0。

我同意Bill在文章中的觀點，在JAX-RS 2.0增加的內容中，最重要的三部分為：

a) Client API——用來規范化JAX-RS客戶端的開發方式。

b) Server-side Asynchronous HTTP——用來實現服務器端推送功能，而不需要依靠低效的輪詢方式。

c) Filters and Interceptors——用來分離關注點，將鑒權、日志等邏輯與業務邏輯分離開，更好地實現代碼重用。

這三部分的內容對于開發者來說都很有用。遵循JAX-RS規范做開發，可以確保服務器端以及客戶端代碼的可移植性。

李建業：我個人關注異步API這部分，主要是因為流式服務將會越來越多，那將大量需要這類支持。

InfoQ：能否為InfoQ的讀者推薦一款實用的RESTful API開發框架，并說明您的推介理由。

李建業：不好意思，這個我不太重視，沒法推薦，不過我可以解釋一下為什么對RESTful API框架不感冒的原因。

REST作為一個架構風格，對我們的系統開發有很大影響，但是這些影響一般是針對架構（例如狀態無關）或者設計（例如資源識別）上的，所以一旦涉及到具體實現，主要工作就基本結束了，此時開發框架能做的事也就只有簡化編程了（相較而言，有的框架還能起到引導設計的作用），而由于RESTful會抽象動詞，所以實現層面中和API規范相關的工作本來就不多，那么框架的價值就更小了。

當然，我們也不可能直接基于servlet/rakc/wsgi來開發，不過一般的編程語言都會提供一些簡單的url route/match策略，我們使用這些就足夠了。另外，有些框架能幫我們生成全部的動詞支持，但這也未必是好事，我一般傾向于按需實現——用到了再支持，這就更不需要太關注開發框架對RESTful的支持了。

丁雪豐：由于本人是Spring的擁護者，工作中也一直在使用Spring，所以在選擇框架時會更多地傾向Spring MVC（并不是說別的框架不好，這里有些個人主觀的成份）。如果一定要選擇其他框架，也要選擇能夠方便與Spring集成的框架。如果在項目中已經使用了Spring，那么沒有什么理由不選擇Spring MVC，鑒于目前Spring在各種項目中的高出鏡率，相信一般情況下都會選擇Spring MVC。

REST的成熟度模型中，第三層就是HATEOAS，Spring目前還提供了Spring Hateoas子項目，對鏈接、資源等方面的支持都做了一定的增強。

馬鈞：我目前在實際項目中使用的是Spray，這是一個開源的 REST/HTTP 工具包和底層網絡 IO 包，基于 Scala 和 Akka 構建。輕量級、異步、非堵塞、基于 actor 模式、模塊化和可測試是Spray的特點。

InfoQ：HTTP2.0規范正在制定當中，您對它的期待是什么？

李錕：我的期待包括兩個方面：應該做的和不應該做的。

HTTP/2.0規范應該做的：

與HTTP/1.1協議保持兼容。兼容的含義是說兩者可以并存，客戶端應用可以根據服務器端的能力，自由地選擇使用HTTP/2.0還是HTTP/1.1，而且選擇過程對應用來說是透明的。

改進HTTP協議（作為資源的統一接口）之中操作語義表達方式的語法，提高網絡傳輸效率。

更好地模塊化，這樣HTTP/2.0協議的實現能夠更好地模塊化。應用程序可根據需要選擇適當的模塊，而不是要么全有、要么全無。

廢棄掉HTTP/1.1協議中一些很少有人用到的部分，例如采用管道（pipelining）方式發送請求。

HTTP/2.0規范不應該做的：

HTTP/2.0協議不應該把底層的數據加密機制（即SSL）作為必選項。

HTTP/2.0協議不應該背離REST架構風格的約束，尤其是要確保操作語義對于中間組件的可見性。

在上面這兩個方面，Roy Fileidng曾經與SPDY協議設計者Mike Belshe發生過激烈爭論，詳情請看：Roy Fielding談Google SPDY協議

李建業：對此規范關注不多，不知道會不會有對于流的支持，目前我所知道的只有chunk方式進行簡單的支持，但是真正的流需要區分數據通道和控制通道——哪怕是邏輯上的區分，這樣就直接對REST風格產生了很大沖擊，考慮到流式服務在未來的發展潛力，我特別期待業界在這方面有所進展。

丁雪豐：HTTP 2.0很大程度上是借鑒了Google的SPDY，就我而言，首先，希望這個規范能做到與HTTP 1.1的兼容，使用者如果只認識1.1，那么2.0能優雅“降級”；其次，希望2.0能帶來更好的性能，SPDY在這方面還是有所改進的，希望HTTP 2.0能再接再厲；最后，希望這個規范能在最終定稿時附帶一個最佳實踐，正確引導人們合理地使用HTTP 2.0。

馬鈞：沒研究過，估計即使出來，1.1還有很長的生命周期，不會很快被取代。

很赞哦!（1）