咱们，来聊聊这个 API设计规范先说说 API是啥玩意。简单来说，它是一种用于API的查询语言，和那种传统的REST API有点不一样，能让客户端来精确指定它需要的数据，不用像原来那样返回来一些用不上的数据，这种能力老厉害了
稳定性和兼容性考量方面
保持 API的稳定性与兼容性，那是相当重要！一方面得跟先前的版本能够继续兼容，想象要是一更新新版本，那些用旧版本应用的用户直接就用不了，本来还用得挺开心的，“哇塞一下”就出现查询错误，体验感那立马就没了严重了还会导致用户直接流失掉！虽说考虑这种兼容性，在开发上会复杂点、成本也增加一点，不过这能让开发周期里少掉返工这个麻烦事，还是挺值得的对
1. 旧有功能，咱得保证它能稳稳地运行着。即便新功能不断有，但别让老功能出毛病
2. 得设计那种稳定可靠的参数结构，既要能支持向后兼容，又能足够灵活，这样以后要加新参数进去就没问题
可扩展性方面
可扩展性就像是衡量 API好不好使的一个重要指标查询，最好采用类似ORM的那种对象模型配置方式。要是不采用这个结构化的对象类型，时间长了，参数列表老长老长的了，这个代码，就不好维护了。比如说添加或者修改一个查询，采用这种方式就不会对现有的结构有啥影响！这得多省事啊是不？举个例子，要是你在玩一款需要不断更新的游戏，更新的时候最好就不打乱原来的玩法框架啥的……这个道理是差不多的！
1. 查询方式要易于在未来加入新元素或者搞改动，又不能牵连以前的啥架构。
2. 名称得符合一定规范，清晰明确，方便人家一眼能明白是干
性能优化方面
在性能优化方面上，有些小技巧很不错
1. 规定采用单入口原则， API和老掉牙的REST AP不一样！人家REST可能每个请求都搞单独的一个URL，我们这个就整一个单一的入口，管理起来方便多咧！
2. 加个HTTP头 - ： gzip，给返回的数据进行压缩，传输的数据一下子就能少下去好多！数据跑起来更快，响应当然就更快！客户端能更快拿到需要的数据，体验上去了
3. 允许有一部分响应字段是空着的！有时候查询的时候要是哪个字段突然有个啥毛病找不到了，如果不给它设成可空状态，那这一整片的数据都可能没法用啦“（┬＿┬）”！
4. 还要考虑分页，毕竟不能对特别深层的数据一次性全量查询，搞分页就合适了，一次看一点数据，这种感觉就很好。
常见问答
Q： 为啥 API不设计成跟REST一样每个请求一个URL
A： 采用单入口原则，能够让API的管理工作轻松一点，你想，要是都多个URL，你想想管理起来得多复杂！而且很多方面都不好统一调整
Q： 那设置一些字段为空有啥用，空了能有啥价值
A： 这作用可大咧！要是没允许字段为空的操作权限，一个字段查询失败可能一下就导致整体的数据结果无法被很好地使用，甚至整个废！设置可空之后就避免这个整体崩塌的可能了
好，总之 API设计规范做好了，不管是实用性方面、可扩展性或者其他，都会更棒有了好的规范去约束去设计，那 API才能跑起来更稳健靠谱我觉得好好遵循这些，指定能设计出好的 API，让用户体验大幅攀升啊。
