這跟是不是springboot沒關係

介面必須提供合法性，合規性，合源性等方面的驗證，如果要做高併發訪問，一定要做叢集，做快取，快取要做好防擊穿，雪崩措施。

合法性：呼叫方式合法，比如類似oauth2.0方式的驗證，通不過拒絕呼叫

合規性：引數是否合規，格式驗證和內容驗證，比如簽名驗證防篡改

合源性：比如呼叫端IP及域名白名單，以及客房問介面配置等

叢集：使用nginx等軟硬體的叢集功能和限流策略，當然你的服務端設計不能有缺陷，每臺介面伺服器都應該能訪問到共用的資源

快取：使用分散式快取，並可自動切換主服務，以免單點故障，邏輯上對請求頻次做限制，只允許同步方式載入資料到快取，切載入前從心判斷快取中是否存在。某資料一直不存在記錄後直接返回特定資料，特定時間不再處理。

1.API介面及常見形式

API是指應用程式程式設計介面，我們透過API介面可以實現特定的功能，而不需要了解其內部實現細節。可以把API介面理解為是特定服務的一種封裝，將服務封裝起來提供給他人呼叫，這樣一來很多功能不需要重新開發。常見的API形式如下：

1、HTTP型別介面

基於HTTP協議提供的API，這類API常常以“網址”形式提供的，像現在主流的RESTful就屬於這類介面。

2、RPC介面

RPC它是指遠端過程呼叫，將一部分程式碼邏輯放在遠端伺服器上部署，然後在需要的地方呼叫即可（呼叫遠端方法就像呼叫本地方法一樣），本質上是Client/Server模式，而且支援多種協議和資料傳輸方式。

3、Web Service 介面

Web Service並不具象地指某種API，我們將以WEB形式提供的服務都稱之為Web Service，像RESTful也屬於Web Service。

2.主要方法

由於需要供第三方服務呼叫，所以必須暴露到網路，並提供了具體請求地址和請求引數，為了防止被別有用心之人獲取到真實請求引數後再次發起請求獲取資訊，需要採取很多安全機制。

(1)請求引數防止篡改攻擊

?客戶端使用約定好的秘鑰對傳輸引數進行加密，得到簽名值sign1，並且將簽名值存入headers，傳送請求給服務端

?服務端接收客戶端的請求，透過過濾器使用約定好的秘鑰對請求的引數（headers除外）再次進行簽名，得到簽名值sign2。

?服務端對比sign1和sign2的值，一致，認定為合法請求。不一致，說明引數被篡改，認定為非法請求。

(2)基於timestamp方案，防止重放攻擊

每次HTTP請求，headers都需要加上timestamp引數，並且timestamp和請求的引數一起進行數字簽名。因為一次正常的HTTP請求，從發出到達伺服器一般都不會超過60s，所以伺服器收到HTTP請求之後，首先判斷時間戳引數與當前時間相比較，是否超過了60s，如果超過了則提示簽名過期（這個過期時間最好做成配置）。

一般情況下，駭客從抓包重放請求耗時遠遠超過了60s，所以此時請求中的timestamp引數已經失效了。

如果駭客修改timestamp引數為當前的時間戳，則sign引數對應的數字簽名就會失效，因為駭客不知道簽名秘鑰，沒有辦法生成新的數字簽名（前端一定要保護好秘鑰和加密演算法）。

注意事項：

headers請求頭帶上了Sign和Timestamp引數

js讀取的Timestamp必須要在服務端獲取

(3)使用swagger介面文件自動生成

透過新增swagger中的@EnableSwagger2等註解，實現透過swagger測試介面，並且自動生成介面文件。