在對接API接口時，接口地址和參數結構都很容易被黑客抓包，從而模擬發送請求。
考慮到安全性，防止別人冒名調用，要對接口請求進行合法性驗證。
基本原理如下
雙方約定
APPID：參與簽名和網絡傳輸
APPSecretKey：約定秘鑰，保存在雙發服務器，只參與簽名，不參與網絡傳輸
簽名方法
調用API時，需要將所有參數名稱以及參數值加入簽名，
即：系統級參數（除去SIGN）名稱、系統級參數值、應用級參數名稱、應用級參數值全部加入簽名。
簽名參數排序
簽名時，根據參數名稱，將除簽名（sign）外所有請求參數按照字母先后順序排序: key + value .... key + value 。 注： 1、排序若首字母相同，則對第二個字母進行排序，以此類推。 2、value無需編碼。 3、對於非必選參數，如果沒有value值，也參與簽名。（說明：非必選參數沒有value值時，將參數名放到字符串中，即參數名要參加簽名） 例如：將“foo=1,bar=2,baz=三”排序為“bar=2,baz=三,foo=1”參數名和參數值鏈接后，得到拼裝字符串bar2baz三foo1。
簽名算法
將分配的得到的密鑰（SecretKey）接到參數字符串尾部進行md5加密（UTF8編碼），再轉化成大寫，
格式是：md5(key1value1key2value2...Secret)。
雙方根據本次請求的參數采用相同的排序生成字符串，並用相同加密算法（一般MD5，也可以用多次加密處理），最后得到的消息摘要sign肯定是一樣的，依次判斷請求的合法性。
服務端在處理的時候要注意多次請求避免重復處理的情況，這時可以通過三方業務唯一標識ID去區分處理，接口響應要保持冪等性（在編程中.一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。）。
當然上面的加密方式消息體依然是明文傳輸的，如果有重要信息，還是有泄露信息的可能性存在。
更高級的方法是參考HTTS的原理，通過公鑰、私鑰進行消息體的加密處理。可參考之前寫的HTTS加密原理 http://www.cnblogs.com/jhli/p/6575828.html
搞定！