“上篇給大家介紹了使用Postman對幾種普通類型的接口請求。但接口類型很多，除了快速上手的那些基本接口外，還有一些特殊的接口，比如簽名接口校驗、攜帶cookie和token的接口等等。今天就接着介紹幾個特殊的接口請求~ ”
01
簽名接口
在寫開放的API接口時，為了保證數據在通信時的安全性，可以采用參數簽名的方式來進行相關驗證。
那么在Postman中怎么校驗這種類型的接口呢？舉例如下：
簽名接口的相關參數：
url：http://www.neeo.cc:6002/pinter/com/userInfo
類型：POST
參數：
{"phoneNum":"1234","optCode":"testfan","timestamp":"12..2","sign":"Md5(手機號+鹽+時間戳)"}
以上信息顯示接口類型為POST，參數類型為json，根據上篇文章可知參數需要填寫在body的raw類型中。具體如下：
參數中需要用到幾個固定字段，這需要我們在接口請求之前定義好。在Pre-request Script中將對應字段定義並賦值(js編碼)，具體如下：
字段賦值后使用md5加密，並將定義好的值set到全局變量中，同時在json參數中引用這幾個全局變量，此時點擊send按鈕，接口就可以正常返回：
同時可以查看全局變量是否顯示在列表中，如下：
ok，經過一系列的操作，我們就將這個簽名接口調通了🤗。
02
攜帶Cookie的接口
首先簡單解釋一下Cookie有啥用~
HTTP協議本身是無狀態的，無狀態就代表服務器沒有辦法判斷用戶身份。Cookie實際上是一小段的文本信息（key-value格式）。客戶端向服務器發起請求，如果服務器需要記錄該用戶狀態，就使用response向客戶端瀏覽器發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器通過該Cookie來辨認請求用戶的狀態、身份等。
說完Cookie的作用，再來看postman如何處理需要攜帶cookie的接口。
先舉例一個場景，用戶需要登錄某網站，登錄成功，返回一個cookie，然后用戶需要攜帶cookie在進行進一步操作，比如查詢余額等。
我們測試這種類型的接口時，有兩種方式：
-
第一種，就是我們使用瀏覽器登錄，獲取cookie值，然后手動攜帶。
-
第二種，就是借助postman幫我們自動的管理cookie值。
先來看第一種方式，查詢余額接口必須依賴登錄成功返回的Cookie。
1、登錄接口的相關參數：
url：http://www.neeo.cc:6002/pinter/bank/api/login
類型：POST 參數：userName=admin&password=1234
2、查詢余額接口相關參數：
url：http://www.neeo.cc:6002/pinter/bank/api/query
類型：GET 參數：userName=admin
首先，我們需要在瀏覽器中訪問http://www.neeo.cc:6002/pinter/bank/page/login連接， 輸入admin&1234進行登錄，登錄成功后，我們獲取到了cookie值。
不要關閉網頁，並保持登錄狀態。此時我們使用Postman做查詢余額接口的請求，在請求中使用獲取到的cookie值(testfan-id=1542a882-7355-47b5-91b0-f8cf052c8560)，如下：
手動攜帶cookie的方式就完成了，但是這種手動方式攜帶的Cookie在網頁關閉之后就立刻失效了，每次請求都需要手動做登錄操作並復制獲取到的Cookie值，相對會比較麻煩。
我們來看第二種，在postman中，新建一個登錄的接口，請求成功之后再請求查詢余額的接口。
此時再請求查詢余額接口就不用攜帶cookie了，直接訪問即可，如下圖：
是不是比第一種簡單多了~
我們查看此次接口請求的cookies欄，發現其中是有值的，那么這個值是怎么來的呢？
這里自動攜帶cookie的原因就在於我們在請求查詢余額接口之前，先請求了登錄接口。在登錄接口請求成功之后，會在本地的MANAGE COOKIES中保存該地址的cookie，如下圖：
此時，postman就自動的幫我們管理了該地址的cookie。當我們再次請求同一個域名 的url時，就會自動將cookie攜帶到請求當中，不用我們每次都手動填寫。而且這種方式也不是一次性的，可以在一段時間內供多個接口請求使用。
上面這個窗口中同樣支持手動添加cookie，如果有需要也可以手動填寫哦~
03
攜帶token的接口
對於token這個詞，測試小伙伴應該都很熟悉吧~ 🥳
Token跟cookie一樣，都是服務端生成的一串字符串。作為客戶端進行請求的一個令牌，當第一次登錄后，服務器生成一個Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數據即可，無需再次帶上用戶名和密碼。
最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進制字符串，可以防止惡意第三方拼接token請求服務器)。
Token的目的是為了減輕服務器的壓力，減少頻繁的查詢數據庫，使服務器更加健壯。在接口測試中，會頻繁碰到攜帶token為參數的接口哦~
那接下來我們就來研究一下postman如何處理需要攜帶token的接口。跟處理攜帶cookie的接口一樣，我們測試這種類型的接口時，有兩種方式：
第一種，就是我們使用瀏覽器登錄，獲取token值，然后在請求查詢余額的接口時將獲取的值手動填寫。
1、從瀏覽器中獲取token值
2、在請求接口時手動填寫token值
第一種方式就醬搞定！✿✿ヽ(°▽°)ノ✿
接着看第二種方式，同樣是借助postman幫我們自動管理token值。
1、登錄接口的相關參數：
url：http://www.neeo.cc:6002/pinter/bank/api/login2
類型：POST 參數：userName=admin&password=1234
2、查詢余額接口相關參數：
url：http://www.neeo.cc:6002/pinter/bank/api/query
類型：GET 參數：userName=admin
1、使用登錄接口，登錄成功之后從響應的json中提取token(tests中的內容會在接口執行完成之后調用，下一篇的斷言中會詳細介紹)，然后將token保存到postman的環境變量中。
接口請求成功↑
token值set到全局變量中↑
2、請求查詢余額接口，在token參數值位置使用全局變量調用{{my_token}}，點擊send：
請求成功↑
ok，醬完事了。
04
webservice類型的接口
webservice類型接口簡單來說，是通過xml進行交互的web請求，本質上也是一種HTTP請求。
Web Service也叫XML Web Service WebService是一種可以接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通訊技術。是通過SOAP在Web上提供的軟件服務，使用WSDL文件進行說明，並通過UDDI進行注冊。
可以通過soupui來測試，也可以通過jmeter來測試。常用webservice接口網站：
http://www.webxml.com.cn/zh_cn/index.aspx
這個網站提供了很多webservice接口，我們可以直接調用測試，主頁如下：
點擊WEB服務按鈕，頁面會顯示可用的各類接口列表，我試了幾個，找了一個結果顯示比較簡單的簡體和繁體字轉換的服務，如下：
點擊EndPoint后面的鏈接，會在頁面中給出兩個選擇，這里選擇簡體轉繁體。
輸入我的名字后，點擊“調用”按鈕：
結果顯示如下：
這就說明這個接口是通的，我們將這個接口(EndPoint后面的鏈接)復制到postman中進行請求。
可能會有小伙伴好奇兩點：1、body中的數據是哪里來的；2、為啥結果顯示的都是？？？
其實在web的接口測試調用的頁面已經在下面顯示了該段數據，如下：
TIP：在Postman中使用時，要記得將string中的值轉換成你想要轉換的值哦~~
至於為啥接口響應的值中顯示的都是？？？，那個是字符類型的原因，可以理解為亂碼，並非響應出錯哦~
為防止有童鞋擔心過程有問題，我又嘗試了一下手機號歸屬地獲取的接口。看下圖，是能夠正常獲取的吧~
至此，webservice的接口就完成調用啦~
今天就給大家介紹這四種特殊的接口類型啦~ 頸椎快不行了，下次接着介紹Postman中斷言和環境設置，我們下次再約咯~🤗
寫在最后： postman真的是一個很有用的軟件，值得所有測試的小伙伴好好研究一下。今天有點晚，就先寫這么多，有興趣的小伙伴可以跟着練一下哦，工具和代碼一樣只要多用多練就熟了，加油哦~💕
希望能夠幫助看到這篇文章的小伙伴，要是覺得不錯的話歡迎分享，有好的建議也隨時歡迎大家指導！我是武愛華，之后有時間會在這里不定期更新，今天就先醬紫，愛你們，👋揮手一分鍾，拜~
