蜜桃av色欲a片精品一区,麻豆aⅴ精品无码一区二区,亚洲人成网站在线播放影院在线,亚洲 素人 字幕 在线 最新

做過開發(fā)的程序猿，基本都寫過接口，寫接口不算難事，與接口交互的對象核對好接口的地址、請求參數(shù)和響應(yīng)參數(shù)即可，我在作為面試官去面試開發(fā)人員的時(shí)候，有時(shí)候會(huì)問這個(gè)問題，但相當(dāng)多的一部分人并沒有深入的考慮過怎么寫好一個(gè)接口，包括接口的可靠性、安全性和高并發(fā)等等。

小編在項(xiàng)目開發(fā)過程中，與很多的企業(yè)對接過接口，包括一些小企業(yè)定制化的軟件接口，也包括一些大廠形成規(guī)范的接口，比如支付寶、銀聯(lián)、微信，以及各大銀行等等，相對來說，很多小廠的接口編寫比較隨意，而大廠對接口的定義就比較嚴(yán)謹(jǐn)，接下來我們就來分析一下。

1、api接口簽名

有過開發(fā)經(jīng)驗(yàn)的程序猿，一般都會(huì)注意到這個(gè)問題，為了接口的安全性，需要對參數(shù)進(jìn)行簽名，防止參數(shù)在請求過程中被篡改。就類似于你的一個(gè)好久沒聯(lián)系的朋友或者同學(xué)，通過微信或者QQ，給你發(fā)了條消息，向你借錢，有一部分人的第一反應(yīng)是他是不是被盜號了？他是本人嗎？所以我們建議通過視頻或者電話再溝通核實(shí)一遍，這就是為了安全性防止財(cái)產(chǎn)的損失。

（1）為什么需要 API 接口簽名？

對外開放的 API 接口都會(huì)面臨一些安全問題，例如偽裝攻擊、篡改攻擊、重放攻擊以及數(shù)據(jù)信息泄露的風(fēng)險(xiǎn)。利用 API 接口簽名能方便的防范這些安全問題和風(fēng)險(xiǎn)。在設(shè)計(jì) API 接口簽名時(shí)主要考慮以下幾點(diǎn)：

• 保證請求數(shù)據(jù)正確

當(dāng)請求中的某一個(gè)字段的值變化時(shí)，原有的簽名結(jié)果就會(huì)發(fā)生變化。所以，只要參數(shù)發(fā)生變化，簽名就要發(fā)生變化，否則請求將會(huì)是一個(gè)無效的請求。

• 保證請求來源合法

一般情況下，生成簽名的算法都會(huì)成對出現(xiàn)一個(gè) appKey 和一個(gè) appSecret，根據(jù) appKey 能識(shí)別出調(diào)用者身份；根據(jù) appSecret 能識(shí)別出簽名是否合法。

這兩個(gè)參數(shù)是非必須的，根據(jù)平臺(tái)的商戶定，比如如果平臺(tái)沒有商戶的概念或者只有一個(gè)商戶，像我們常見的自己的客戶端對接自己的服務(wù)端。但是像一些提供接入能力的平臺(tái)，比如微信，很多企業(yè)都可以接入，那他就需要區(qū)分不同的商戶，每個(gè)商戶分配一個(gè)appId，然后再通過appKey+appSecret來區(qū)分調(diào)用者的權(quán)限。

• 識(shí)別接口的時(shí)效性

一般情況下，簽名和參數(shù)中會(huì)包含時(shí)間戳，這樣服務(wù)端就可以驗(yàn)證客戶端請求是否在有效時(shí)間內(nèi)，從而避免接口被長時(shí)間地重復(fù)調(diào)用。

（2）簽名實(shí)現(xiàn)邏輯

 

各家在簽名時(shí)的請求參數(shù)可能有一點(diǎn)差別，但整體實(shí)現(xiàn)邏輯是類似的。

第一步：將除sign外的所有請求參數(shù)放入集合Map中；

第二步： 將第一步得到的集合M中的參數(shù)按照參數(shù)名ASCII碼從小到大排序（字典序）;

第三步：將第二步中排序后的key和與之對應(yīng)的value拼接起來，使用URL鍵值對的格式（即key1=value1&key2=value2…）得到字符串 params；

第四步：在params的最后再拼接appKey密鑰，然后通過某種加密算法或通過hash算法得到 sign 值（一般為Base64(HMAC_SHA1(params, appSecret))）；

第五步：sign加到params 中，將params放入請求頭中發(fā)送請求目標(biāo)接口；

（3）簽名實(shí)現(xiàn)代碼

我們會(huì)常用到幾個(gè)參數(shù)：

version：版本號

charset ：字符編碼

sign_type：簽名類型，如RSA、RSA2、SHA

timestamp：當(dāng)前時(shí)間戳，格式Y(jié)YYYMMDDhhmmss，在服務(wù)端會(huì)驗(yàn)證比對請求方的時(shí)間與系統(tǒng)當(dāng)前時(shí)間差，若超出太多，比如超過十分鐘，就認(rèn)為這個(gè)是過期的請求，不允許獲取數(shù)據(jù)。

nonce_str：隨機(jī)字符串，隨機(jī)以主要保證簽名不可預(yù)測。每次請求時(shí)都不一樣。

2、加密算法

對于一些比較敏感的私人信息，接口傳輸過程最好進(jìn)行加密傳輸，比如用戶姓名、手機(jī)號、身份證號碼等。如果需要明文保存，可以使用AES雙向加密解密，如果直接保存加密的數(shù)據(jù)，可以使用md5加密。

（1）md5加密

MD5加密是一種不可逆的加密算法，不可逆加密算法的特征是加密過程中不需要使用密鑰，輸入明文后由系統(tǒng)直接經(jīng)過加密算法處理成密文，這種加密后的數(shù)據(jù)是無法被解密的，只有重新輸入明文，并再次經(jīng)過同樣不可逆的加密算法處理，得到相同的加密密文并被系統(tǒng)重新識(shí)別后，才能真正解密。很多網(wǎng)站為了安全性，會(huì)額外再加一個(gè)鹽值（一串隨機(jī)字符串）一起進(jìn)行加密，提高加密的安全性。MD5鹽值加密作用就是為了防止MD5被暴力破解。通過鹽值和密碼進(jìn)行組合計(jì)算得出MD5，在數(shù)據(jù)庫中要同時(shí)存儲(chǔ)該MD5碼及鹽值。在需要驗(yàn)證密碼正確性時(shí)，可以將密碼和數(shù)據(jù)庫中對應(yīng)賬號密碼的鹽值組合計(jì)算出的MD5與數(shù)據(jù)庫中的MD5進(jìn)行比對。

另外一些網(wǎng)站號稱可以對md5加密的密文進(jìn)行解密，他們只是手機(jī)了足夠多的密碼信息，來進(jìn)行匹配，反向推導(dǎo)出加密前的明文，實(shí)際上是無法真正的實(shí)現(xiàn)md5解密的。

（2）AES雙向?qū)ΨQ加解密

AES是一種分組密碼 分組長度為128位（16字節(jié)），根據(jù)密鑰長度可分為AES-128 AES-192和AES-256，密鑰長度不同，AES的加密輪數(shù)也不同。

AES的工作模式分為ECB、CBC、CFB等

ECB是最簡單和最早的模式，首先是密鑰擴(kuò)展，將加密的數(shù)據(jù)按照16字節(jié)的大小分成若干組，對每組都用同樣的密鑰加密。

CBC和ECB的區(qū)別就是添加了一個(gè)初始向量（16字節(jié)），在將密鑰分成若干組之后，第一組與初始化向量異或之后再進(jìn)行與ECB相同的加密流程，后面的每一組都與上一組的密文進(jìn)行異或之后再與密鑰加密。

3、編碼解碼

（1）為什么會(huì)出現(xiàn)亂碼

在計(jì)算機(jī)中，不管是一段文字、一張圖片還是一段視頻，最終都是以二進(jìn)制的方式來存儲(chǔ)。也就是最終都會(huì)轉(zhuǎn)化為 0001 1000 這樣的格式。換句話說，計(jì)算機(jī)只認(rèn)識(shí) 0 和 1 這樣的數(shù)字，并不能直接存儲(chǔ)字符。所以我們需要告訴它什么樣的字符對應(yīng)的是什么數(shù)字。但是如果用戶A定義的編碼規(guī)則，傳到B使用了另外一套解碼規(guī)則進(jìn)行解碼，由于編碼和解碼的規(guī)則對應(yīng)不上就導(dǎo)致了亂碼。

（2）怎么解決亂碼

這就需要我們了解java中的編碼轉(zhuǎn)換。雙方定義好編碼方式，我們以utf8和gbk這兩種常見的編碼為例。

4、接口token鑒權(quán)

有一部分人會(huì)把token鑒權(quán)和接口加簽搞混，我們來梳理一下這兩種方式。

使用Sign簽名，是為了對接口參數(shù)進(jìn)行驗(yàn)證，我們在業(yè)務(wù)開發(fā)過程中與上下游系統(tǒng)進(jìn)行接口對接時(shí)，常采用這種方式，那為什么不是token方式呢，因?yàn)槲覀儾恍枰卿浬舷掠蜗到y(tǒng)，他們在攔截器層面已經(jīng)放行了這些接口，不需要登錄后才給調(diào)用。而像我們管理平臺(tái)上的接口，比如查詢某個(gè)列表的數(shù)據(jù)，就不能直接調(diào)用接口，需要先登錄系統(tǒng)才有調(diào)用接口的權(quán)限。

Token是用來判斷用戶身份的一個(gè)標(biāo)識(shí)，身份驗(yàn)證通過了，才能調(diào)用接口，token也是一種加密方式，使用用戶的信息進(jìn)行加密，一般可以使用md5加密，我們來看一下token鑒權(quán)的過程。

第一步：用戶使用賬號密碼登錄，向服務(wù)端發(fā)起http請求

第二步：服務(wù)端校驗(yàn)賬號密碼數(shù)據(jù)

第三步：驗(yàn)證成功后，服務(wù)端會(huì)生成一個(gè)token，并將這個(gè)token返回給客戶端

第四步：客戶端收到這token后將它放在cookie或者本地存儲(chǔ)

第五步：客戶端再次向服務(wù)器發(fā)起請求時(shí)帶上token

第六步：服務(wù)端收到請求，然后驗(yàn)證客戶端請求里面帶著token來判斷權(quán)限，如果驗(yàn)證成功，就向客戶端返回請求的數(shù)據(jù)。

5、接口示例

以上分析了這么多，接下來我們就來看一下各大廠定義的接口規(guī)范，有哪些值得我們學(xué)習(xí)的。

銀聯(lián)：

支付寶（支付寶需要引入支付寶的sdk，支付寶sdk內(nèi)部進(jìn)行了封裝）：

招商銀行：

  業(yè)務(wù)實(shí)施流程