開發接口的時候，一定要對數據進行過濾，這個就不提了。
重要的是，怎么確保對接口調用的自我保護和限流、降級機制，這個從何說起呢？
比如，你寫了一個接口，該接口並沒有什么bug，但是接口沒漏洞不代表系統沒漏洞，如果有人調用你的接口，然后成功了，這證明你的接口沒問題。
但是，如果出現這種情況：接口調用方 高並發地 調用你的接口，其實你的接口是沒問題的，但是你的服務器承受不住呀，也許對方不是故意的，但如果是對方發生狀況，出現了這種情況，就比較傷心了，所以寫任何接口之前或者之后，都要考慮這個問題，不要存在僥幸心理，不然真出現問題，受罪的還不知道是誰呢
注意：上面說的情況很類似於DoS攻擊，請注意，只是類似於，當然也可以將DoS攻擊考慮在內，因為他們是有區別的。
之所以說不是DoS攻擊，是因為，DoS攻擊在TCP三次連接的過程中，只發送SYN包，但是並不會對服務器發揮的SYN ACK包進行確認，即並不會發送ACK給服務器。通過這種方式來消耗系統資源，讓系統崩潰。
而如果是一個服務異常請求的，因為他出現了bug，頻繁的請求你的接口，你的服務器和請求方是完成了三次握手，每一次連接都是合法的，單從連接狀態上，是判斷不出什么異常的。所以對於這種情況，采用防DoS的手段來解決問題，驢頭不對馬嘴。
你寫的接口，可能涉及到數據庫操作（不涉及數據庫操作的接口很少吧），那么涉及數據庫的連接數，數據庫的最大連接數 和 服務器的最大連接數，以及數據庫同一時刻能運行SQL的數量，如果是php，還涉及php-fpm，這里面的每一項，都有臨界值，如果出現意外，超過臨界值也是很正常的，只不過看超過了哪一項的臨界值而已，臨界值大的，可能堅持的時間會久一點。
如果你的接口涉及到數據庫操作，特別是查（select)操作，請盡量使用從庫（或者讀庫）進行操作。一般情況下，都建議接口中對從庫進行操作。
如果你有很多接口，接口的使用方是不同的服務系統，可能你的一個接口提供給一個系統調用，也可能提供給多個系統調用。那么在進行限流的時候，你就得注意了，如果你是根據單位時間內接口的訪問量來判斷，如果超過某個閥值，就阻止對該接口的訪問，那么就會出現這個問題：其中一個系統頻繁調用接口，超過了閥值，於是你就拒絕了之后對該接口的請求，即使此次的請求方不是之前頻繁請求的那個請求方，都會被拒絕掉，有種株連九族的意味。
於是，你就想，當然不可能讓其他的系統認為是接口掛了，你可以返回一些message，告訴用戶，出現了什么問題，應該采取什么措施，同時觸發一些異常處理，比如發郵件呀，IM通知，短信通知呀，其實最好的是電話通知。暫時性的拒絕用戶的請求，比 等服務器崩潰之后重啟，所引發的損失要小一點（這個要看實際情況）。
聰明的你一下就想到，可以為每一個系統頒發一個token，他們每次訪問接口的時候，都會想判斷token是否合法，之后會記錄該服務在單位時間內訪問該接口的次數，如果超過某個規定的閥值（每個系統的閥值可以不同，可以針對優先級設置），就阻止下一次攜帶着這個token的請求。這樣的話，也不會妨礙其他用戶的訪問，是一個不錯的辦法。
如果采用上面的做法，可能會遇到這種情況：各個接口的閥值都沒超，但是多個接口或者其他的服務，綜合起來，總量卻是超過了負載，一下服務器就崩了，各種通知呀，全都沒法運行了，其實一般不會存在這個問題的，因為一般都會有個資源超過某個值就會觸發報警。但是，你的系統 和 操作系統 不是等同的呀，有時候，沒報警，但是你的服務就是掛了，你能咋辦，干瞪眼呀。你可常見的做法，“探活”，即 每個多長時間，請求一次某個資源，如果響應5xx，就觸發報警