说实话，我非常希望两年前刚准备找实习的自己能看到本篇文章，那个时候懵懵懂懂，跟着 上的免费教程做了一个购物商城就屁颠屁颠往简历上写。
至今我仍清晰地记得，那个电商教程是怎么定义接口的：
管它是增加、修改、删除、带参查询，全是 POST 请求一把梭，比如下面这样：
现在看来，全部用 POST 请求估计是为了传参方便吧。
- 初识 API 接口
- 关于 API 限流
- 关于 API 版本管理
- 关于 API 权限与安全
- 关于团队间的 API 互通
1. 初识 API 接口
记得在我初学 web 开发的时候，后端框架相关的教程基本都会教学生写渲染模版（不分语言），也就是说后端返回的是整个 页的数据，浏览器只负责渲染。
一般这类模版在后端都会对应一个路由，比如前端想登入一个看用户信息的页面，在 url 中输入的访问地址大概长这样：
那个时候，我以为这样的路由地址就是 API 概念的全部了…
值得一提的是：绝大部分后端教程都会简单教一下前端，在前端的补充教程中有一个必学的知识点，叫：AJAX。
老师大概率会演示一下 AJAX 这个技术怎么使用，写个小 Demo，告诉大家可以这样在页面上发送异步请求。
这个技术请求的后端接口一般不会跳转或返回一个 html 页面，大概率会返回一份 json 数据。我一直对这样的接口和返回页面数据的接口有着迷之困惑。直到我大三实习时明白了什么叫前后端分离开发…
后来导师提醒我：你需要去了解一下如何设计 REST 风格的 API。
自从那次出丑后，我明白了一个事情，一定要敢于把自己的不足”暴露”给愿意指点你的人看。就好比我们读大学的时候最好要努力去找一份实习，每一次被拒以及每一份 offer 都会告诉我们，这个 会需要什么样的人才，什么样的技能可以帮助我们谋得一份工作。
在正式的面试场合下，或许我们更应该条理清晰地和面试官介绍什么是表现层状态转换，但是在这篇文章中，我想把 REST 风格的 API 称为更容易让人看懂的 API。
大家会发现符合 REST 风格的 API 能非常容易地让别人知道调用这个 API 能干什么，比如：
按约定写 API 就好比在 IT 领域说行话，大家只要看见你的 API，就知道你能提供什么样的服务。
有同学可能会好奇为什么要遵守规范p>
假如，我们负责的系统仅联系到我们身边同事的系统，那约定 API 的时候只需要打个招呼，或在聊天工具上简单说明一下就可以了，甚至可以没有文档。
但在很多情况下，我们的系统是要被很多其他系统调用的，大家想象一下我们去调用云厂商 API 的场景：别人的工程师大概率不是我们的微信好友，大多数时候是没有人站在我们身边手把手告诉我们 API 怎么调用的。这个时候想调用对方提供的 API，就得看对方提供的 API 文档。如果对方的 API 不按照规范定义，那 API 文档绝对像天书一样难读。
看天书的痛苦，保证大家体会一次足以终生难忘。
2. 关于 API 限流
API 写出来后会被调用，但由于计算机 & 络系统的局限性，我们的 API 接口是不可以被无限制调用的。
大家可以随便到 上挑一个比较专业的 API 文档看，比如大家可以去看云厂商对外提供的 API，基本都会看到一个接口频率调用限制，比如：单用户调用频率为 30 次 / 秒。
所以当我们在设计 API 的时候，限流是一个不得不考虑的事情（内部自己弄着玩的不算哈，泛指面向用户的系统）
在设计限流之前，我们首先要知道自己系统的瓶颈。假设我们的 API 纯粹调用自家的技术组件，比如数据库，消息队列等中间件，这个时候我们可以通过压测得知一个接口的最大承受能力；假设我们的系统是一个中间系统，需要依赖其他系统的接口完成业务，那么这个时候基于木桶原理，我们接口的可访问频率就会受限于其他业务系统。
了解完自身项目的访问瓶颈后，需要考虑自身系统的架构，假设我们的系统是单体部署：
这个时候上面的 15 行代码显然就不符合我们的分布式系统架构，我们得考虑更复杂的限流算法实现了（这里不是指令牌桶算法不合适，是指令牌桶算法的实现方式需要改进），当然这个实现大概率会放在代理层了，而不是实现在我们的业务层。
大家可以上 看一下主流云厂商提供的云服务，很多都会提供 API 关，对应着我们上面提到的代理层。
假如一个公司有统一的 API 关服务，或有类似的代理服务，业务部门是可以在 API 限流这件事情上省下很大功夫的。我有时候想，当越来越多的中小企业基于巨无霸云厂商搭建业务，大家要考虑的技术性问题就会越来越少，越来越专注于业务，这到底是一件好事还是坏事呢p>
4. 关于 API 权限与安全
接着我们要思考一下 API 的权限与安全问题。
还是回到初学的时候，那个时候我对 API 接口权限完全没有任何概念。老师为了快速教会我们开发系统，很多接口的设计是完全裸奔的。如果不了解一点点相关的知识，工作中会容易给别人一种考虑事情不周到的感觉。
在实际生产中，接口是不可以不做权限校验的，如果我们的系统暴露在公 ，还没有权限校验的话，系统估计很快就挂了；内部涉及机密的系统，权限校验则更为严格。
关于权限校验，个人暂时分为三个维度，三个维度或许可以对应三种业务类型：
- 第一种是直接针对 IP 设置白名单，这种方式比较适用于客户端有限且固定的内部系统；
- 第二种则是设置权限校验流程，比如采用 Token 鉴权，较多用于 ToB 业务。大家在云厂商注册账 后基本都会得到一对密钥，后续的 API 调用一般都需要先根据密钥进行权限认证；
- 第三种是通过用户登陆判断权限，较多用于 ToC 业务，比如我们登陆京东，登陆淘宝需要账 ，没有登陆就访问不了购物车等页面。
值得一提的是，权限设计是另一个维度的知识，除了第一个维度，后两者其实都可以单独成立一个系统的。比如公司的用户管理系统，中心化权限认证系统等等。
权限校验关乎着公司财产安全，所以不可忽视，很多时候我们甚至需要在 API 设计层面考虑安全问题。再次引用商城的例子，比如登陆后获取用户购物车的订单，API 大概率会设计成这样子：
但直接暴露用户 id 或许不是一个明智的选择，有可能被不法分子利用，我们可以换种方式，比如用以下的方式替代：
总而言之，API 的设计除了参考规范外，还需要根据自身业务情况进行更进一步的安全考虑。
5. 关于团队间的 API 互通
最后是一个延展性话题，相信大家都感受到了我们正身处于一个数据时代，我们的个人信息，包括各类行为喜好，都存放在各家互联 公司的数据仓库里，企业们可能比我们更了解我们自身， 上也有很多与数据资产有关的话题。
既然已经把数据比作资产了，而资产流动性又是一个经久不衰的话题，所以各类数据的开放性问题也很受关注。而数据对外开放，必然就会涉及到 API 接口。
当然作为一只小码农，我的视野极其有限，很难从一个较高的层次去谈论企业的数据问题。但在工作中，当其他业务团队提出要调用自己负责的项目的 API 接口时，也是需要进行多方位考虑的。
- 你能看懂我的 API 嘛li>
- 别把我的 API 打爆哦！
- API 要经允许才能使用哦！
由于API 的这个概念实在是太大了，我能接触的也是一些些皮毛，但时不时总结整理一下还是大有裨益的。
最近要着力负责项目的开发，所以戏谑的漫画可能会稍微少一些些，会更多地分享自己在实践过程中关于工程的思考。下期再见咯～
文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8829 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！