移动端接口开发经验一二

从 传统的项目开发转到移动互联网开发已经半年有余，经历了许多，刚刚转行时期的压力山大，渐进掌握诀窍的得心应手。本人出于出版行业，现在这个行业面临着拥抱互联网的浪潮，如果不积极的拥抱互联网，传统的出版行业迟早要逐渐消亡。

需求：

现在需要一个平台级别的管理 内容提供者，和内容运营者的 系统。

做了很多项目之后，我个人认为，很牛的项目都是贴近用户需求，做出来的，而不是设计出来的。因为用户的需求是万变的，我们在最初做需求调研的时候，可以尽可能多的挖掘用户的需求，不放过蛛丝马迹。但是尽管如此， 随着项目的进行，需求还是可能像雪花一样纷飞而至。

由于需要管理 内容提供商，内容运营上，项目的权限模型初期采用

用户 —角色--  菜单 模型，进行控制。开源的本人比较熟悉shrio，此开源的项目使用起来比较方便。

dao层，mybatis 可以适应读写分离，和简单的性能调优等，

spring MVC 框架 现在差不多是市场的主流，最好用的还是它的AOP和IOC特点。

前台界面，真心感谢bootstrap 这个优秀的前端框架 

由于考虑到后期开发中的需求的频繁变动，移动端接口，与服务器端项目采用分开开发的模式。

移动端接口开发目前经常使用的是采用JSON模式传输数据

或者未来可能为主流的resful 模式，此模式可以充分利用URL地址，将一些与业务逻辑无关的参数通过URL地址进行处理。增加项目的规范化。

或者采用webservice 

由于具体的需求是后期 接口需要对外，根据不通的权限提供不通的服务，

此时初期接口权限验证采用了

和服务器端 类似的 client   + role  + 菜单URL 格式

服务器端可以针对 每个 具体的调用接口的App分配一个clientId 和secret

APP在请求接口的时候，需要 根据具体的规则 例如 

clientId + 时间戳 + secret 然后进行MD5后封装到请求头后，服务器端对请求进行系统级别的权限鉴定。

系统级别的鉴定通过后，然后再通过接口权限列表进行权限鉴定。

APP开发的时候，需要双方约定好，返回的状态位

例如封装对象 

responseBean {

String msg;//返回消息

string Object data;//封装返回的数据

Integer status;//封装返回的状态

}

具体的状态可以定义个全局的常量类，以便于后期的调整

Gloable{

public static final Integer SUCCESS=0;//请求成功

……

}

针对一些变化不大的且服务器端和移动端共用的数据，可以采用memcached进行缓存，在系统启动后，根据具体的情况，进行数据加载。服务器端改动后，进行重新加载。

注意memcached 需要做好安全隔离。

如果服务器端项目可能有多个版本的时候，需要用SVN ，进行多个版本的控制，在主版本上打个分支 ，然后在主版本上改动后，通过 合并，把最新的需要合并的代码合并到分支上。