接口统一管理设想

* 现存的问题
* 统一管理实现方案
* 例子展现

##现存的问题##

* 趋势要求
    >公司逐渐在往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. 这个例子是我在上家公司作的接口管理程序，客户端的程序员不再来咱们服务端要接口文档了，并且接口是否健康他们能一目了然。