接口设计

编程的基本原则:

1.职责单一
2.开闭原则
3.迪米特原则(最少知道原则)
4.依赖倒置原则
5.里氏替换原则
6.接口隔离原则

接口基本原则:

1.  简洁且完备
2. 语义明确且符合习惯
3.数据可复用
4.可扩展性
5.兼容性(多个端 , 多个版本)
7.安全性
8.廋客服端/服务端集权

接口规范

接口示例:以获取个人信息
1.极简且完备: 不要冗余 不要缺失

{
    "message": "处理成功",
    "status": 1,
    "result": {
        "userPhone": "手机号",//上下文已知是用户信息了, user多余
        "type": "推荐类型", // 信息不完备,属于过度解构, recommendType
        "name": "姓名",
    }
}

2.语义明晰,符合习惯
登录接口:

{
    "message": "处理成功",
    "status": 1,
    "result": {
        "userCode": "员工编码",
        "userPhone": "手机号",
                "is_publish" //一个字段请只表示一层含义,这个接口表示:是否发布 另一个接口表示:是否公开
                "cname":"className",//杜绝完全不规范的缩写，避免望文不知义
        "name": {

        },
        "class": {
            "cId": 1,
            "cName": "一年级"//上下文已知是class了, 就自己用name不好吗; 可读性差; 结构不得复用
        },
        "grade": {
            "gId": 1,
            "gName": "一年级"
        },
        "lesson": {
            "lId": 1,
            "lName": "语文"
        }
    }
}

3.瘦客户端
业务逻辑尽量写在服务端:
避免兼容老版本
出现bug,可即时修改发布

{
    "message": "操作成功!",
    "result": {
        "name": "张三", 
//根据审核状态显示对应文字2(审核中), 不要写死在客户端
//1.如果变更客户端就要改不能即时发布,而且老版本是无法修改
//2.如果加状态, 就是兼容老版本
        "auditStatus": 2, //审核状态参看2.1 
    },
    "status": 1
}

4.接口升级兼容
同一个接口的字段避免:删除 修改(修改字段名, 修改含义);
可以添加字段
对修改关闭,对扩展开放
5.单一职责
一个字段只表示一层含义,
如果表示两层含义, 其中一个含义要变更 , 另一个无关的含义逻辑也要变更
其它注意项:
避免返回浮点型数据, 用整型或字符串代替