博主不大擅長寫作，但看了《高效能程式設計師的修煉》一書，不得不改變下自己。本文是對最近使用web service做專案時，討論的總結。如有錯誤，歡迎勘正，共同提高。第一次寫技術部落格，難免邏輯和條理不清，也請指點。本著分享和學習的目的，歡迎拍磚！
主要分次三部分：
-restful風格
-開放api的技術要點
-驗籤
傳統的web服務，是在http基礎上，通過soap和wsdl協議封裝的分布式可重用元件。在概念上是基於操作的，所以服務通常用動詞命名。與之相比較，restful並不是一種技術，它是一種架構風格，在概念上它是針對資源的。資源及其狀態轉變可以呈現／展現（hateoas），這些是restful的核心。作為http協議的主要設計者，roy thomas feilding指出了人們對http協議的濫用，同時自然的利用http協議原本含意來闡述 restful web服務。所以首先restful web服務是輕量級的，因其直接基於http協議的，另外還必須符合restful風格。這裡就不再對如何使用http動詞使用作介紹了。博主覺得resftul的難點在資源uri設計。
如何保護資源只供受信任的使用者訪問。這和正常的互動式應用一樣。一般都會給受信任方發放憑證。由於web服務要求訪問是無狀態的。常見的實現方式有三種：
1）每次訪問都驗證身份：這種方式需要每次提供憑證，首先伺服器驗證憑證，通過後進行業務處理。
2）但最常見的每次驗證做法是使用金鑰驗籤。這種做法將身份驗證和防篡改一起做掉了。方法簡單，對技術要求少（不需要https），也不用直接傳送憑證，所以這種方式也很流行。
3）第一次訪問時，做一次登入以生成token，以後使用該token請求服務，博主認為這種做法應該是趨勢。首先只需要一次驗證；其次符合責任單一的原則；最後用token代替每次傳送憑證提高安全性，即使被劫持也可以隨時清理token（是否有點勉強？）。當然這種做法最好用https，以防登入時憑證被盜取。
防止資料在從客戶端提交到伺服器過程中被篡改是互動設計必須考慮的。現在基本上已經有比較一致的方法就是通過驗簽來保證。
對敏感資訊的保護（如使用者個人資訊，財產資訊等等）應該是各種開放api必須考慮的。但目前國內在這一塊的重視程度遠遠不夠。這個可以在傳送過程中對資料加密來完成，通常使用https來達到。
重放攻擊是利用原有的合法請求來破壞開放資源或者客戶端伺服器連線關係，也有兩種方法：
1） 一般請求上傳都會帶時間戳，可以通過對時間戳的判斷解決，比如超過5分鐘，則請求無效。這種做法簡單而且高效，但不能避免短時間內的多次重放攻擊
2） 客戶端為每次請求生成唯一序列號，伺服器首先驗證該序列號的請求是否被處理。如果沒有則處理請求並記錄該序列號對應請求處理完成；有則忽略該請求。這種方法代價稍高，但可以不受重放攻擊。
現在來介紹下在做驗簽時的考慮。驗籤原來是被設計來防止資訊篡改。首先在一次請求中，客戶端通過將一些業務資料加上驗籤金鑰作為輸入，採用資訊摘要演算法（如md5，sha1等）計算出驗籤碼，再將這些業務資料和驗籤碼隨請求一起傳送至伺服器端。在伺服器端，使用同樣的方法計算驗籤碼，並將之與從客戶端傳送上來的驗籤碼相比較，如果一致則表示業務資料沒有被篡改。
傳統的面向操作的web服務，基本上會將業務資料全部放入查詢引數或者請求體中，所以可以很容易的在正式業務處理之前做統一驗籤。這也是很合理，因為驗籤是技術性的，非業務相關的。這也使得很多非restful web服務（像支付寶介面），可以很自然地設計出統一驗籤方法。
而在restful方式下，情況稍微複雜些，因為資源uri內包含了業務相關資料；而且每個資源當動詞不一樣時業務處理也是不一樣的；此外不同資源的uri內包含的業務資料及其個數也是不一樣的。也就是說，uri和動詞已經變成了業務的一部分。另外，還很有可能某些資訊既出現在uri中，也出現在請求體中；這也導致出另乙個問題，資訊不一致時如何處理。那麼在這樣的情況下，又如何來做驗籤呢？而且是統一驗籤，並在驗籤之前不涉及業務處理。參考了很多開放介面，目前可能還是仁者見仁，還沒有一致的看法。看見過以下3種做法：
1）將資源uri和動詞忽略，只對請求引數和請求體做驗籤。這種方法假設主要業務資訊都在請求引數和請求體中，並且動詞不會被篡改。這種做法還是存在質疑的。
2）只對url和動詞做驗籤，忽略請求體。這種方法假設url中已經包含所有業務相關的引數資訊，url不會變（經過load balance和反向**）；此外請求體中不包含額外的關鍵業務引數。這種做法和前面一樣同樣讓人質疑。
3）對url和動詞以及請求體全部做驗籤。這種方法假設url，動詞和請求體三者互補的構成業務處理所需的引數資訊。做法1）和2）都是在不一致時取某乙個為準，驗簽前不做校驗。而這種方法假設只要驗籤通過，資料不會存在不一致的情況。這種假設也是比較合理的。使用這種方法時要求資源使用方，確保資訊不衝突，最好做到資訊是正交的。另外需要注意的是，在有load balance和反向**的情況下，url不能發生實質性的改變而影響驗籤。
總結一下：個人傾向於使用https＋token ＋完部驗籤的方式做開放api的開放
開放API設計安全考慮
1.加密敏感資料保證安全，非對稱演算法rsa和對稱演算法des sm4等 2.摘要演算法md5防止篡改，演算法中增加鹽值 雙方約定的乙個秘密值 增加伺服器時間值，用於判斷呼叫提交時間 3.採用token的方式校驗是否已經登入，乙個是判斷token是否存在，二是token是否過期 4.介面設計需要具有...
前端開發API 豆瓣開放API
目錄前言 具體api 1 豆瓣熱映 2 電影top250 3 電影條目檢索 4 條目詳情 前後端的分離，在和後端對接之前，前端開發人員除錯的時候，總是面對沒有真實資料的尷尬地位。雖然有mock.js可以模擬資料，但是始終只是在本地進行模擬。而豆瓣提供的這些公開的介面，相信可以滿足大部分前端的開發。遺...
免費開放介面API
2017 11 25 更新 女性個性網名獲取介面 介面說明 page 1 頁碼 備註 當page 0時，會隨機返回一頁資料，page 1時會返回相應頁碼的資料。返回值 美圖獲取介面 介面說明 page 1 頁碼 備註 當page 0時，會隨機返回一頁資料，page 1時會返回相應頁碼的資料。返回值 ...