Api接口是什么意思？怎么编写一个合理严谨的接口？（API接口知识小结）

做过开发的程序猿，基本都写过接口，写接口不算难事，与接口交互的对象核对好接口的地址、请求参数和响应参数即可，我在作为面试官去面试开发人员的时候，有时候会问这个问题，但相当多的一部分人并没有深入的考虑过怎么写好一个接口，包括接口的可靠性、安全性和高并发等等。

小编在项目开发过程中，与很多的企业对接过接口，包括一些小企业定制化的软件接口，也包括一些大厂形成规范的接口，比如支付宝、银联、微信，以及各大银行等等，相对来说，很多小厂的接口编写比较随意，而大厂对接口的定义就比较严谨，接下来我们就来分析一下。

1、api接口签名

有过开发经验的程序猿，一般都会注意到这个问题，为了接口的安全性，需要对参数进行签名，防止参数在请求过程中被篡改。就类似于你的一个好久没联系的朋友或者同学，通过微信或者QQ，给你发了条消息，向你借钱，有一部分人的第一反应是他是不是被盗号了？他是本人吗？所以我们建议通过视频或者电话再沟通核实一遍，这就是为了安全性防止财产的损失。

（1）为什么需要 API 接口签名？

对外开放的 API 接口都会面临一些安全问题，例如伪装攻击、篡改攻击、重放攻击以及数据信息泄露的风险。利用 API 接口签名能方便的防范这些安全问题和风险。在设计 API 接口签名时主要考虑以下几点：

• 保证请求数据正确

当请求中的某一个字段的值变化时，原有的签名结果就会发生变化。所以，只要参数发生变化，签名就要发生变化，否则请求将会是一个无效的请求。

• 保证请求来源合法

一般情况下，生成签名的算法都会成对出现一个 AppKey 和一个 appSecret，根据 appKey 能识别出调用者身份；根据 appSecret 能识别出签名是否合法。

这两个参数是非必须的，根据平台的商户定，比如如果平台没有商户的概念或者只有一个商户，像我们常见的自己的客户端对接自己的服务端。但是像一些提供接入能力的平台，比如微信，很多企业都可以接入，那他就需要区分不同的商户，每个商户分配一个appId，然后再通过appKey+appSecret来区分调用者的权限。

• 识别接口的时效性

一般情况下，签名和参数中会包含时间戳，这样服务端就可以验证客户端请求是否在有效时间内，从而避免接口被长时间地重复调用。

（2）签名实现逻辑

各家在签名时的请求参数可能有一点差别，但整体实现逻辑是类似的。

第一步：将除sign外的所有请求参数放入集合Map中；

第二步： 将第一步得到的集合M中的参数按照参数名ASCII码从小到大排序（字典序）;

第三步：将第二步中排序后的key和与之对应的value拼接起来，使用URL键值对的格式（即key1=value1&key2=value2…）得到字符串 params；

第四步：在params的最后再拼接appKey密钥，然后通过某种加密算法或通过hash算法得到 sign 值（一般为Base64(Hmac_SHA1(params, appSecret))）；

第五步：sign加到params 中，将params放入请求头中发送请求目标接口；

（3）签名实现代码

我们会常用到几个参数：

version：版本号

charset ：字符编码

sign_type：签名类型，如RSA、RSA2、SHA

timestamp：当前时间戳，格式YYYYMMDDhhmmss，在服务端会验证比对请求方的时间与系统当前时间差，若超出太多，比如超过十分钟，就认为这个是过期的请求，不允许获取数据。

nonce_str：随机字符串，随机以主要保证签名不可预测。每次请求时都不一样。

2、加密算法

对于一些比较敏感的私人信息，接口传输过程最好进行加密传输，比如用户姓名、手机号、身份证号码等。如果需要明文保存，可以使用AES双向加密解密，如果直接保存加密的数据，可以使用md5加密。

（1）md5加密

MD5加密是一种不可逆的加密算法，不可逆加密算法的特征是加密过程中不需要使用密钥，输入明文后由系统直接经过加密算法处理成密文，这种加密后的数据是无法被解密的，只有重新输入明文，并再次经过同样不可逆的加密算法处理，得到相同的加密密文并被系统重新识别后，才能真正解密。很多网站为了安全性，会额外再加一个盐值（一串随机字符串）一起进行加密，提高加密的安全性。MD5盐值加密作用就是为了防止MD5被暴力破解。通过盐值和密码进行组合计算得出MD5，在数据库中要同时存储该MD5码及盐值。在需要验证密码正确性时，可以将密码和数据库中对应账号密码的盐值组合计算出的MD5与数据库中的MD5进行比对。

另外一些网站号称可以对md5加密的密文进行解密，他们只是手机了足够多的密码信息，来进行匹配，反向推导出加密前的明文，实际上是无法真正的实现md5解密的。

（2）AES双向对称加解密

AES是一种分组密码 分组长度为128位（16字节），根据密钥长度可分为AES-128 AES-192和AES-256，密钥长度不同，AES的加密轮数也不同。

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

ECB是最简单和最早的模式，首先是密钥扩展，将加密的数据按照16字节的大小分成若干组，对每组都用同样的密钥加密。

CBC和ECB的区别就是添加了一个初始向量（16字节），在将密钥分成若干组之后，第一组与初始化向量异或之后再进行与ECB相同的加密流程，后面的每一组都与上一组的密文进行异或之后再与密钥加密。

3、编码解码

（1）为什么会出现乱码

在计算机中，不管是一段文字、一张图片还是一段视频，最终都是以二进制的方式来存储。也就是最终都会转化为 0001 1000 这样的格式。换句话说，计算机只认识 0 和 1 这样的数字，并不能直接存储字符。所以我们需要告诉它什么样的字符对应的是什么数字。但是如果用户A定义的编码规则，传到B使用了另外一套解码规则进行解码，由于编码和解码的规则对应不上就导致了乱码。

（2）怎么解决乱码

这就需要我们了解JAVA中的编码转换。双方定义好编码方式，我们以utf8和gbk这两种常见的编码为例。

4、接口token鉴权

有一部分人会把token鉴权和接口加签搞混，我们来梳理一下这两种方式。

使用Sign签名，是为了对接口参数进行验证，我们在业务开发过程中与上下游系统进行接口对接时，常采用这种方式，那为什么不是token方式呢，因为我们不需要登录上下游系统，他们在拦截器层面已经放行了这些接口，不需要登录后才给调用。而像我们管理平台上的接口，比如查询某个列表的数据，就不能直接调用接口，需要先登录系统才有调用接口的权限。

Token是用来判断用户身份的一个标识，身份验证通过了，才能调用接口，token也是一种加密方式，使用用户的信息进行加密，一般可以使用md5加密，我们来看一下token鉴权的过程。

第一步：用户使用账号密码登录，向服务端发起http请求

第二步：服务端校验账号密码数据

第三步：验证成功后，服务端会生成一个token，并将这个token返回给客户端

第四步：客户端收到这token后将它放在cookie或者本地存储

第五步：客户端再次向服务器发起请求时带上token

第六步：服务端收到请求，然后验证客户端请求里面带着token来判断权限，如果验证成功，就向客户端返回请求的数据。

应用程序接口API（Application Programming Interface），是提供特定业务输出能力、连接不同系统的一种约定。这里包括外部系统与提供服务的系统（中后台系统）或后台不同系统之间的交互点。包括外部接口、内部接口，内部接口又包括：上层服务与下层服务接口、同级接口。

本文站在产品经理角度由浅入深讲述接口相关知识。如果不想被视为技术大佬眼中什么都不懂的需求搬运工，清楚接口的相关知识是很有必要的。

常见web接口是http/https协议的接口，多用于外部系统或前端系统的调用，因为此类接口地址要暴露在外部，所以必须对接口的安全性做较高程度的校验。还要一种基于开源rpc构建的跨系统接口调用接口方案，此类主要用于大公司内网各系统间的互相调用，此类接口服务治理能力更强，接口相应速度更块。以下内容以http接口为例展开的讨论。

一、接口请求方式类型

常见的http请求方式包括：get（查）、post（增），除此之外还有put（改）、delete（删）等。接口所属类型是由业务决定的。比如你打开淘宝，展示的首页内容就需要用到get接口，获取页面信息，你看中了宝贝要下单，添加你的收获地址时，用的则是post接口。而这两种也是其中最常见的两种接口类型

1）get类型接口

格式：请求数参数写在网址后面，用”?”连接，多个参数之间用”&”连接。

场景：get型接口用于获取信息，多用于查询数据，如菜单列表展示，搜索展示，订单查询，优惠券查询等需要其他系统返回数据时使用。一般情况下请求的数据量较小，返回速度快，不过接口是暴露在外面的，所以会有一定的风险。

2）post型接口

说明：向指定资源位置提交数据（如提交表单、上传文件）来进行请求，post请求可能会导致新资源的建立。

场景：如注册、上传、发帖等功能，这种请求数据量大，安全性要求高。

其他接口类型如put（改）、delete（删）、patch等使用评率稍低一些，此处不再赘述。

二、接口响应机制类型

从返回上区分，分为 同步接口、异步接口

1）同步交互

指发送一个请求,需要等待返回,然后才能够发送下一个请求，有个等待过程；

比如登录接口，执行登录操作时，将用户名、密码、token等字段加密后通过接口校验，需要返回验证结果后，才能登录成功。

2）异步交互

指发送一个请求,不需要等待返回,随时可以再发送下一个请求，即不需要等待。

如用户领导优惠券，只需要将用户的领券行为请求成功，资产系统收到请求后异步操作用户发券，通过异步的方法执行发券，调用方无须等待每个请求的调用结果。

区别：一个需要等待，一个不需要等待，在不影响用户体验的情况下，我们的项目开发中一般会优先选择不需要等待的异步交互方式。

哪些情况建议使用同步交互呢？比如用户登录、银行的转账系统，对数据库的保存操作等等，都会使用同步交互操作，其余情况都优先使用异步交互。

三、接口的触发形式类型

1）分发接口

一个系统产生新数据的时候就分发给其它系统（也可以是多个）。

中台系统的核心思想是高内聚、低耦合，所以分发接口的使用场景还是比较多的。比如有一个主渠道系统来管理所有的渠道数据，而渠道数据是其他系统如商品系统、促销系统经常要使用到的信息。所以一旦出现新的渠道或者发生渠道变更，需要分发给其他所有对接了各个系统，实现对最新渠道的功能支撑。

2）订阅接口

一个系统在需要的时候调用其他系统的接口进行数据订阅。

比如订单系统生成订单时，因为很多外部系统可能需要及时获取订单状态信息。而订单系统也不知道要分发给哪些系统，这时候一般会将订单推送至特定的消息队列，比如KFK，其他由需要跟进订单状态的的系统订阅KFK消息后，可以即使获取订单完成信息，进行触发下一个动作。

四、其他API接口基本组成

再既定的业务下，接口请求类型、响应机制等确定后，再以微信支付API为例，了解下接口的其他组成内容。

1）应用场景

顾名思义，此接口适用于的场景，明确接口的业务用途。

2）入参及出参

入参是接口请求所需要的变量参数，其中包括必填参数和非必填参数，非必填并非是可以忽略的，比如上面的入参中，签名类型为非必填，如果未传此参数，则默认此签名类型为MD5，如果使用的并非此类签名类型，则此项为必填项。如果是普通订单查询，入参时间非必填，则返回结果是用户全部订单，或者用户特定时间订单的区别。

3）错误码

接口请求并非每次都能成功，所以在接口开发时会对可能失败的情况进行错误码区分，在接口联调时可以根据返回的错误码快递定位问题。如果错误码不够全面，那在接口调用失败的时候，需要反复定位，降低开发效率。

五、接口安全性校验

接口完成业务逻辑开发后，接下来要考虑的就是安全性问题了，接口的安全性问题主要来源于几方面考虑：

1）请求来源是否合法？

即接口的伪装攻击，因为接口是对外的，在公网环境中，接口地址是暴露的，收到的请求有可能是恶意非法请求；如果真的是合法请求，也需要知道这个请求的来源，同时这个请求来源不能否认。这里引入“签名”的概念，以及签名的防伪装及抗否认性特性。

近些年各大企业强制使用https替换掉原有的http接口，正是因为https所使用的的证书安全性更高。

2）请求是否会被篡改，返回数据可能会被截取

因为接口是对外的，所以接收请求和返回数据的时候，是不可能使用明文方式传输的，否则一旦被恶意截取，会造成极大风险。所以请求数据及返回数据都是需要加密的，这样即使数据被截取，也不用泄露数据的内容。这里介绍几种现在常见的加密方法。

DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合；

3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高；

RSA：非对称加密，由 RSA公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的；既可以实现加密，又可以实现签名。

如果是用户账号相关，现在会使用token加密用户信息，用户请求身份信息时，服务端会分配token存在缓存中，后续请求会将token与时间戳一起打包加密，这样即使请求数据被截获，因为不知道token的值，数据也不会被解析出来。

3）如何防范接口的重放攻击，防重放攻击是什么呢？

就是把你的请求原封不动地多次发放，请求都会通过验证进入到正常逻辑中，会造成服务端接口拥堵并且会造成实际损失。

防重放一般需在请求参数加上 时间戳 + 随机数，通过时间戳确保接口是最新的请求，而随机数相同则可以认定为是重放攻击。

六、接口性能相关

如果是访问量比较大的接口，再上线前肯定需要进行压力测试。因为普通的开发自测和生产模拟是不能推算出高并发时候接口是否可正常运行。

1）TPS

Transaction Per Second 每秒系统处理的交易或事物的数量，衡量系统处理能力的重要指标。

2）RT

响应时间，从客户端发送一个请求开始，到客户端接收到从服务器返回的响应结果结束所经历的时间，包括请求发送时间，网络传输时间和服务器处理时间三部分。

3）吞吐量

指的是在一次性能测试过程中网络上传输的数据量的总和。

用户的响应时间自不必说，时间太久伤用户体验，及时处于高并发期，用户的响应时间依然需要控制到最低，一般不超过5s；

tps则是高并发的指标，一般提供服务的接口，需要考虑到最极端情况下的并发数，这些数量一般来自于运营的活动策划和往期的数据趋势预估，以此为依据，保证自己的接口可以支持最高的并发数，而验证这些使用的一般是压力测试。如正常情况下压测时tps可以达到2000时接口正常，就可以保证2000的实际并发。

七、接口需要做哪些测试

接口测试其实是白盒测试，首页要明确系统的能力输出，明确服务覆盖是否满足需求。以业务逻辑推接口参数。

1）入参不符合要求需要有明确错误码，报错信息和日志，方便问题复现与定位。

2）如果另有参数处理逻辑的链路，也需要一并验证，如购买网易云音乐会员，订单生成后会去权益系统加权，加权成功后会有短信通知用户，但加权接口和订单信息中都没有用户手机号，所以虽然入参中没有用户手机号，但需要根据用户的username去查询手机号，并执行短信发放的操作。

其他验证目标如：代码覆盖率是否达到要求、性能指标是否满足要求、安全指标是否满足要求则是更为专业性的测试指标了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。