* 现存的问题
* 统一管理实现方案
* 例子展示
##现存的问题##
* 趋势要求
>公司逐渐在往SOA架构上靠近，各个系统相互协作，接口服务层出不穷，随之产生的就是，接口安全、协议、文档、维护、升级、监控等问题。
* 接口书写不规范，见缝插针
>现在每个项目里面，都有自己对外提供的接口，接口写的位置各不一样，而且注释、文档都不具备，所以除了接口人本身，没有人知道接口在哪里及实现的原理，调用及返回的协议，参数的规范等， 所以就形成了一个单点。
* 接口文档形同虚设
>接口文档管理， 这个事情是所有程序员比较头疼的，不想写文档是人性，所以文档总是跟不上接口的变化，文档就成了摆设。
* 接口监控
>FAT、UAT、BETA、PRO 我们现在的四个环境，但是每个环境，都没有接口可用率的监控，出问题后，没法定位是哪个接口的问题，只能在程序里debug，久而久之，对于不重要的环境就置之不理了，这也是大部分公司FAT、UAT环境不好用的原因。
##统一管理实现方案##
* 定义统一接口规范，及安全策略
1. HTTP 协议
2. HTTP header 缓存策略（对于无线很实用）
3. HTTP header 定义接口版本。
4. HTTP heaer 缓存策略。
5. 请求、响应的编码规范。
6. 响应的格式统一。
7. 针对不同接口定义安全策略。（白名单、业务策略、统一签名）
* 接口书写规范
1. 启一个API_CENTER项目，所有业务及可验证接口统一写在该项目中，对于已有的老的接口，可以采用转发请求的方式接入该项目，从而实现统一位置可见、统一位置可验证。
2. 接入方需要接入什么接口服务，不需要联系接口人，只需要到该项目中查找对应接口即可，而接口人也不需要直接为接入方服务，只要保证在该项目中，接口在不同环境下时可用即可，这样就大大降低了沟通成本及验证成本。
* 接口文档走配置化
1. 在API_CENTER项目中的接口、或者是有该项目做转发的接口，需要在该项目中统一的配置文件中，添加自己的配置，配置内容大致为：
1. 接口采用的协议。
2. 接口请求地址。
3. 接口所需参数、参数类型、参数编码、参数是否可选、默认可用实例。
4. 是否需要HTTP缓存。
5. 接口返回格式（json、xml、string）尽量统一json
6. 接口名称
7. 接口描述
这样做的好处是，省去了繁琐的接口文档的编写，而且只要程序可用，文档永远都是最新的。
##例子展示##
1. 这个例子是我在上家公司做的接口管理程序，客户端的程序员再也不来我们服务端要接口文档了，而且接口是否健康他们能一目了然。
本文出自 “架构技术文摘” 博客，请务必保留此出处http://wufaliang.blog.51cto.com/3160882/1543586
原文地址：http://wufaliang.blog.51cto.com/3160882/1543586
