作者在20年末遭遇黑产：我跟黑产斗争的故事（二），提到当时未对接口进行加密处理，被人刷短信接口一事，现根据经验提出集中api接口加密思路供参考，当然我的思路和方法也是参考了网上现有的一些方法。
方法二：在请求参数中加入经过计算的签名参数。
此方法是参考的互联网上已有的方法，感觉实践性比较好，安全性较高。方法思路是：在客户端请求的时，将所有请求参数（又或者排除特定的参数之后）经过某一个计算方法得出一个签名。
实际应用举例：
一、服务器端：在服务器后台建立n组app_id和secret，以便对应app或者小程序的不同版本，也就是在每一个版本的app或者小程序中代码中都埋入特定的app_id和secret，且预先设计好每一组app_id的加密方法，这样方便随时管理不同版本的app或小程序的加密方法是否启用或者弃用，在发现某一个版本的app或小程序加密方法被破解后可以果断禁用并更新新版本使用新的加密方法。
二、客户端：在小程序或者app中发起请求前，将所有请求参数，去掉特定名称的参数之后，先排序，排序之后，取每个参数的名称和值不超过10个字符拼在一起组合成一个字符串，然后截取字符串的前32位，再在这个字符串的后面或前面拼接上对应的secret，然后进行md5加密，得到签名参数sign，请求中将对应的app_id和计算过的sign一起加入到参数中发送给服务器。
三：服务器处理：服务器接收到请求参数后，根据接收到的app_id，在后台根据对应的加密方法一样对参数进行计算得到sign，然后和http请求传入的sign参数进行比较，看是否对得上。
在实际应用中，一样的注意：一是使用更安全的https链接。二是如此操作必然需要一个公共的发起请求的函数，那可以稍微把代码搞乱一点，不要生怕别人读不懂代码。
在计算sign的过程中如果需要更复杂的计算，还可以加入请求的时间戳、对字符串进行特定的字母替换混淆等等。
当然此方法也有一几个缺点，就是每次请求都需要进行加密计算，必然也就增加了服务器的负担。