020博客地址汇总2019年博客汇总
这里想和大家讨论的是在后台接口设计过程中，还有哪些方面需要考虑，以及还有哪些优秀的技术实践方案可以借鉴。【规范和最佳实践】合理的接口命名；接口的命名必须规范优雅，在未看到接口文档时，就可以根据接口的URL明白接口的功能是什么？如下面的例子：
//好的接口命名示例
/customer/cert/search.json
//不好的接口命名示例
/customer/info/get.json入参和出参的规范化定义，有统一的风格；一个项目内的所有接口，必须有统一的风格，统一返回格式，约定业务层错误编码，每个编码可以携带明确的错误信息。出入参字段含义明确，采用统一的命名规范，如驼峰命名等。返回格式统一采用json格式。举一个例子：
{
'status': 'failure',
'error_code': 100003,
'error_message': '未获取到用户信息',
'data':
}status标识接口是否逻辑处理成功；error_code为不同类型错误信息对应的唯一错误码，error_message为错误信息的简要描述信息，data则为需要返回给调用方的数据信息。每个参数一定要有明确且固定的数据格式，int就是int，string就是string，array就是array，object就是object，因为对于一些对数据类型要求比较严格的使用方，不明确的数据格式返回，可能会造成不可预知的错误。下面给大家列一下Json里的六种基本数据格式：
Number：整数或浮点数String：字符串Boolean：true或falseArray：数组包含在方括号中Object：对象包含在大括号{}中Null：空类型
接口的功能定义要具备单一性；单一性是指接口要做的事情应该是一个比较单一的事情，比如登陆接口，登陆完成应该只是返回登陆成功以后一些用户信息如uid即可，但很多人为了减少接口交互，返回一大堆额外的数据。但有时候对于一些内部系统接口来讲，为了实现通用性，可能会提供一些通用的查询接口，即在同一个接口内返回尽可能多的信息，但也不建议这么做，至少不是一个好的实践；明确接口支持的协议；接口要明确所支持的协议，是POST/GET/PUT/DELETE等的哪一个。一般来讲，同一个接口而言，尽量只支持一种协议，并且在接口被调用时，如果参数传递非接口定义协议，要明确提示返回错误信息，这样可以减少很多类似于“为啥我调接口参数都对还调不通”的问题的沟通成本。严格的协议规范也可以避免一些意料之外的问题出现。例如：
您请求的资源不支持 http 方法“POST每个接口有各自的版本，一般为接口添加个version的参数。整个接口系统有统一的版本，一般在URL中添加版本号，比如http://apzkbhcom/v
【性能和高可用】接口的平均响应时长、支持的并发数、TPS；这个很重要，无论是我们自己设计的接口，还是我们在使用第三方提供的接口时，我们都需要明确接口的平均响应时长，因为这直接关系到你系统的安全性问题！如果在接口调用时，没有设置合理的超时时间甚至都没有设置超时时间，那么一旦所以依赖的接口出现问题甚至服务不可用时，对你调用方系统来讲，将是致命的，雪崩式的系统崩溃，很大一部分就是由于这个原因造成的。所以为了不害人害己，设计以及最终提供的接口，一定要提供一个明确的接口平均响应时长，而且要在接口文档中写明并强烈建议接口调用方设置合理的超时时间，防止由于接口超时而造成雪崩式的连锁反应。数据库和缓存的选择；为了提高接口性能，合理的选择数据库和缓存很是总要。一般情况下，关系型存储我们一般都会选择MySQL数据库，缓存一般都选择Redis。MySQL数据库的分库分表，加索引用事务、读写分离等，redis作为缓存使用时的缓存时长、缓存数据类型等，都有他们的使用原则和最佳实践，这里不做赘述。我们这里只讨论在何种场景下要使用缓存。比如查询类型的接口，如果要查询的数据并不是实时性要求很高的接口，那我们可以进行缓存处理，比如APP首页接口，一般都是CMS里面配置的一些文信息，我们有必要做缓存处理。当然可能里面有一部分数据是需要实时的，比如自如寓的管家信息，那我们可以把这一部分内容做实时的处理。限流、熔断和降级；对于一些特殊的应用场景，比如抢红包、秒杀等，要对接口进行限流处理，方式短时间内的高并发请求将接口搞死；接口熔断和降级，是为了解决系统不被拖死，不影响核心业务流程而采取的措施，比如获取用户信息列表，实时获取用户头像和昵称的接口暂时不可用，我们可以主动放弃调用，只返回核心数据uid等，昵称和头像暂时返回默认数据；消除单点，负载均衡；对于任何一个接口服务，我们至少要有2台机器对外提供服务，禁止单点服务，单点一旦出问题，会直接造成服务不可用；对于访问量很大的API服务，为了提供更加快速的接口响应，我们往往不是单台机器提供服务，而是有多台机器组成一个分布式集群对外提供服务。这个时候就会涉及到负载均衡，比如我们就会由nginx来做负载均衡，根据一定的策略机制，将接口请求平均的分发到不同的应用机器上进行处理和响应。进而提高接口的性能。是否有第三方服务接口？如果接口依赖了第三方服务接口，能用缓存就用缓存。这样可以进一步降低由于第三方接口不稳定给我们自己系统造成的波动。也有一些第三方接口无法做缓存，比如就是要实时进行身份验证等，这个时候，超时时间的设置就尤为重要！能异步处理的异步处理：其实有很多场景下，一个接口里面的很多逻辑是可以异步处理的。举个例子：比如用户注册场景，用户注册成功之后会给客户的邮箱发送一封激活邮件。常规的逻辑流程应该是，前段提交用户信息到注册接口，注册接口做各种校验，校验通过后，发送邮件，发送成功后，返回给前端告诉用户注册成功，请进入邮箱激活账号。这个流程里的“发送邮件”就是可以拿出来异步处理的部分，当校验通过而且注册完成之后，我们把发送邮件这件事抛出去，交给另外一个就负责发邮件的任务进行处理，然后直接返回给用户注册成功。这样，注册接口的平均响应时间一定会比第一种方案提高很多。更高要求的高可用，可以采用异地机房部署；在物理地域上就分开部署，两地同时崩溃的概率还是比较低的；监控和报警；在对接口建立高效的监控和报警机制，能够及时发现问题并通知到相应的人员进行第一时间的处理和跟进。【稳定和安全】身份验证；在一些接口场景中，是要依赖于用户身份的，比如通过token还实现用户身份的验证；接口防抓取和串改数据；防止数据被轻易抓取到，我们可以采用https作为接口的网络传输协议，进而保证数据包不被轻易的就抓取和分析。即使这种情况下，依然被抓取到，我们还可以对传输的数据进行我们自己的加密处理，比如用对称加密算法AES或者非对称加密算法RSA，亦或是我们系统内部自己商定好的加密算法，对数据进行加密处理，这样，即使抓取到数据包，也很难分析出数据的原始信息。对于防止数据被串改，可以使用sign验签，进一步防止接口参数被串改的可能性。防刷；接口防刷会有一些策略，根据实际的应用场景进行选择，比如增加形验证码、接入智能验证码、时间戳限制单位时间内的调用次数、ip限制等；另外监控很重要，及时发现异常的调用，进行封禁处理；【其他】是否需要支持跨域；这一点是针对于H5提供接口时需要考虑的，因为一般情况下，实际的应用和接口所在的域并不是同一个域，基于浏览器的安全策略，对于XHR请求来讲，是不允许进行跨域请求的，一般提供给H5的接口要支持跨域请求。当然解决跨域的方法也不在本次讨论的范围之内，目前主流的方式就是在服务器配置的header头信息中增加两项参数。基于H5提供接口的一些安全性问题；比如常见的CSRF攻击，我们可以在接口里验证HTTPReferer字段、x-requested-with字段、header中增加token等，从一定程度上提高被CSRF攻击的门槛。在代码结构层面，尽量和其他部分分开；API集中由同一个系统“模块”提供，尽量不要和页面等其他功能混合开发。例如下面的项目分层模式就是一个较好的实践方案：
即所有API接口均分布在api内部，不与pc、mobile等混合在一起。文档：好的接口，还有一项优点，就是会有为之配套的接口文档。如果希望降低接口文档的维护成本等，也可以使用开源的第三方自动化接口文档工具，比如swagger等。
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论