App架构设计学习（一）---- 接口的设计

1、哎，最近换了家工做，结果工做很出的我意外，没有干熟悉的根据需求写代码，反而让我一个小菜鸟去重构一下App的架构（他们公司的app，已经上线了1.0版本了），没办法，只有硬着头皮去先学习学习，再总结总结。

 Hybrid APP架构设计思路 ---> https://segmentfault.com/a/1190000004263182

二,App与服务器的通讯接口如何设计得好,能够从如下这几个方面考虑

  一、 安全机制的设计  

        ----> 待研究

  二、 接口数据的设计      

　　接口的数据通常都采用JSON格式进行传输，不过，须要注意的是，JSON的值只有六种数据类型：

　　Number：整数或浮点数

　　String：字符串
　　Boolean：true 或 false
　　Array：数组包含在方括号[]中
　　Object：对象包含在大括号{}中
　　Null：空类型
　　因此，传输的数据类型不能超过这六种数据类型。之前，咱们曾经试过传输Date类型，它会转为相似于"2016年1月7日 09时17分42秒 GMT+08:00"这样的字符串，这在转换时会产生问题，不一样的解析       库解析方式可能不一样，有的可能会转乱，有的可能直接异常了。要避免出错，必须作特殊处理，本身手动去作解析。为了根除这种问题，最好的解决方案是用毫秒数表示日期。

　　另外，之前的项目中还出现过字符串的"true"和"false"，或者字符串的数字，甚至还出现过字符串的"null"，致使解析错误，尤为是"null"，致使App奔溃，后来查了很久才查出来是该问题致使的。这都是      由于服务端对数据没处理好，致使有些数据转为了字符串。因此，在客户端，也不能彻底信任服务端传回的数据都是对的，须要对全部异常状况都作相应处理。

　　服务器返回的数据结构，通常为：

　　{
　　code：0
　　message: "success"
　　data: { key1: value1, key2: value2, ... }
　　}
　　code: 状态码，0表示成功，非0表示各类不一样的错误
　　message: 描述信息，成功时为"success"，错误时则是错误信息
　　data: 成功时返回的数据，类型为对象或数据
　　不一样错误须要定义不一样的状态码，属于客户端的错误和服务端的错误也要区分，好比1XX表示客户端的错误，2XX表示服务端的错误。这里举几个例子：

　　0：成功
　　100：请求错误
　　101：缺乏appKey
　　102：缺乏签名
　　103：缺乏参数
　　200：服务器出错
　　201：服务不可用
　　202：服务器正在重启
　　错误信息通常有两种用途：一是客户端开发人员调试时看具体是什么错误；二是做为App错误提示直接展现给用户看。主要仍是做为App错误提示，直接展现给用户看的。因此，大部分都是简短的提示信      息。

　　data字段只在请求成功时才会有数据返回的。数据类型限定为对象或数组，当请求须要的数据为单个对象时则传回对象，当请求须要的数据是列表时，则为某个对象的数组。这里须要注意的就是，不要将      data传入字符串或数字，即便请求须要的数据只有一个，好比token，那返回的data应该为：

　　// 正确
　　data: { token: 123456 }

　　// 错误
　　data: 123456

  三、接口版本的设计

　　接口不可能一成不变，在不停迭代中，总会发生变化。接口的变化通常会有几种：

　　数据的变化，好比增长了旧版本不支持的数据类型
　　参数的变化，好比新增了参数
　　接口的废弃，再也不使用该接口了
　　为了适应这些变化，必须得作接口版本的设计。实现上，通常有两种作法：

　　每一个接口有各自的版本，通常为接口添加个version的参数。
　　整个接口系统有统一的版本，通常在URL中添加版本号，好比http://api.domain.com/v2。
　　大部分状况下会采用第一种方式，当某一个接口有变更时，在这个接口上叠加版本号，并兼容旧版本。App的新版本开发传参时则将传入新版本的version。

　　若是整个接口系统的根基都发生变更的话，好比微博API，从OAuth1.0升级到OAuth2.0，整个API都进行了升级。

　　有时候，一个接口的变更还会影响到其余接口，但作的时候不必定能发现。所以，最好还要有一套完善的测试机制保证每次接口变动都能测试到全部相关层面。

3、只是为了记录学习别人的知识，好的地方是直接粘贴过来的，请各位看官见谅。