1.索引规则 : 业务上具有唯一特性的字段，即使是组合字段，也必须建成唯一索引。

个人理解：（原则每一层数据，只有一个索引id）
实际应用中：原则做过类似项目，出现很多索引id，图斑id，自然幢id，标识码，任务id，户id等。导致接口很乱，因为每一个id对应的key不一样，容易出错。每一级的数据应只有一个索引。
此项目只用到两层（建筑和户），只需要两个索引就行。

2. 统一规范返回数据的格式，对己对彼都有好处，此处以json格式为例。返回数据应包含：返回状态码、返回状态信息、具体数据。

{
        Status: 状态码
        Message：“成功或者失败理由”
        Data{
}
}

前台弹出返回json串的message信息，可以让前台用户，清楚知道出问题原因。例如（用户名不对，密码不对，填写数据有瑕疵等提示）

3. 接口返回数据原则

            *.  前台需要哪些字段，api接口应返回哪些字段，不应该少，也不应该多
（不只是会显得乱的问题，如果是list展示，返回数据过多，接口速度，传输会变慢）
            *.  返回数据结构要和数据一致性（数组数据就是数据，对象就是对象，而不是返回数量为1的数组）
            *.  返回数据量，数量不确定（有可能很大的），应提前做好分页。

            *.  布尔值类型:统一使用字符串’0’和’1’来表示假和真，性别 0代表未知或者保密，1男2女。

            *.  不返回Null类型数据

4.命名规则

     *接口名，参数名，返回数据名称，不出现拼音，或者拼音首字母缩写的。

     *不同页面相同的数据，应使用统一参数名字。 例如（城市住宅，城市非住宅，等不同表里边，省市县，姓名，等应使用统一参数名称）

5.好的习惯（一些好的习惯，就会避免一些问题的产生）

      *应遵守单页面，单接口规则，避免一个界面请求多个接口。
      （例如提交的时候，如果分成多次提交，有可能出现，有的接口提交成功，有的失败的情况，出现垃圾数据）
     *路径应给全，而不是前台去拼接。（例如返回图片的路径，前台拼接，后台如果改变路径，前台需要对应改路径，发新版本，图片会不能显示）
      *

6. 请求方式

    *post：新增数据
     * get：获取数据
Get参数有长度限制，参数过多用post，登录更新密码等与用户信息有关的优先用post。