开发十年，就只剩下这套Java开发体系了 >>>   

    Open API即开放API,也称开放平台。 所谓的开放API（OpenAPI）是服务型网站常见的一种应用，网站的服务商将自己的网站服务封装成一系列API（Application Programming Interface，应用编程接口）开放出去，供第三方开发者使用，这种行为就叫做开放网站的API，所开放的API就被称作OpenAPI（开放API）。

    以前的软件开发都是针对特定的用户或群体进行设计,但用户的需求是千差万别的,众口难调就是这个道理。随着软件开发的发展,人们的关注点和设计模式也在悄悄发生着变化,我与其针对特定客户进行开发,不如站在大众的角度进行设计,把自己从甲方乙方的魔咒中解禁出来,自己成为甲方。也就是说我以前开发的软件只给你用,你还不满意,现在我只提供核心业务,你自己来对接,你想设计成什么样子就设计成什么样子。于是 Opean Api 应运而生！！淘宝、阿里、腾讯都是这么干的,人家是大公司,规则的制定者,人家怎么规定接口,你就得怎么对接！！有一个网站叫 聚合数据 专门提供一些免费的和收费的优秀 API,有兴趣的可以上去注册玩玩。

    关于如何开发这样的一套接口,刨除实际的业务逻辑不说,我们来看看怎么设计?下面是我在设计的时候遇到问题的思考,可能不全面仅供参考!

先来看看有那几点需要考量?我也是凭经验和 Google。

1. 签名鉴权（我需要知道请求我的是谁,有没有访问这个接口的权限）
2. 流量控制（我不可能让你随随便便就无节制的访问我,我要能随时关停你）
3. 请求转发（请求过来的 url,需要找到真正的业务处理逻辑,api最好只负责接口的规范,不负责业务的实现）
4. 日志处理（你可以保持沉默,但你说的每一句话都会成为呈堂供证）
5. 异常处理（即使老子内部出了问题,你也不会看到我的异常堆栈信息,我会告诉你我病了,请稍后再试）
6. 参数规范（顺我者倡,逆我者亡）
7. 多机部署（我有九条命）
8. 异步回调（别想阻塞我,但我可以玩死你）
9. 错误信息（你要认识到自己错误）

    做API,尤其是 Open API 最重要的就是安全、安全、安全,试想一下,你的接口我可以随随便便就猜对账号密码,随随便便就可以DDOS 你,你都没有办法保证用户信息的安全,谁还敢用你。其实你是在做一件反黑客的设计,呵呵,是不是高大尚了很多。

Client:你怎么知道一个请求是我而不是别人呢?

API:你如果对接我,我给你起一个全世界唯一名字就吧,你请求的时候就告诉我你叫 xxx,赋值到请求中的app_key中就行,至于这个字段叫app_key还是叫 UserName还是叫 client_id,这个看你心情了。于是就有了接口的第一个功能,给客户起一个唯一名字。

Client:如果别人也知道了这个用户名,冒充我怎么办?

API:我还会给你一个配套的密码,密码只有你我知道,你请求的时候,把密码带过来,我先验证密码,密码通过了我才允许访问。这样就没人能冒充的了你了吧。你密码丢了,那就是你自己的事情了。

Client:现在 HTTP 都是明文通信,我每次访问都带上我的账号密码,那不等于广而告之天下吗?就像拿着一袋子钱在路上边走边喊“快来抢我呀！快来抢我呀！”，一个小小的嗅探器就能把用户的密码拿到手，如果用户习惯在所有地方用一个密码，那么你闯大祸了，黑客通过撞库的方法能把用户的所有信息一锅端。

API:那就就用你的账号密码先到我这儿换取一个口令吧,我们叫 token,这样携带口令且口令正确的我们就认,没有携带口令或口令不正确的我们几回绝,这样你就不用带着密码满世界跑了。

Client:但是那如果 Token 被截获了呢？黑客重放怎么办！！

API:这个口令是有一个过期时间的比如10分钟、一个小时、一天、3个月等等,你们也可以做到单点登录,我这边也可以有效的控制外人的入侵,同时避免了重复信息的反复查询数据库和对比等操作,绝对可以提高响应速度,校验 token 的有效性花费的时间绝对比查数据库要来的快啊。我们在服务器端接口被调用时就可以对发起请求的ip地址、user-agent之类的信息作比对，以防止伪造。再然后，如果token的有效期设得小，过一会儿它就过期了，除非黑客可以持续截获你的token，否则他只能干瞪眼。

Client:这个可以,但是我第一次输入密码的时候还是有可能被窃取啊?

API:那就上 HTTPS ,密码什么的用 SSL 加密协议传输,我看谁还能窃取到呢?你要还纠结呢咱就上非对称?

Client:…

API:还有话说么?没话说就老老实实对接

网络攻防

1. CORS
2. CSRF
3. 劫持攻击
4. DDOS
5. XSS
6. SQL注入
7. 文件上传漏洞
8. 缓冲区溢出