接口描述：用户登陆成功后，或进入首页时会获取一次用户信息。
| URI |
方法 |
| /userinfo |
GET |
请求参数
| 名称 |
必填 |
备注 |
| id |
是 |
用户id |
响应参数
| 名称 |
类型 |
备注 |
| id |
String |
用户id |
| name |
String |
姓名，例：张三 |
| age |
String |
年龄，例：20 |
json示例
{
"code":200,
"msg":"成功",
"time":"1482213602000",
"data": {
"id":"1001",
"name":"张三",
"age":"20"
}
}
- 基本规范
<ol><li><a href="https://blog.csdn.net/weixin_38229356/article/details/83155559#21__44">公共参数</a></li> </ol></li>
公共参数是每个接口都要携带的参数，描述每个接口的基本信息，用于统计或其他用途，放在header或url参数中。例如:
| 字段名称 |
说明 |
| version |
客户端版本。1.0.0 |
| token |
登录令牌 |
| os |
手机系统版本。12 |
| from |
请求来源。android/ios/h5 |
| screen |
手机尺寸。1080*1920 |
| model |
机型。IPhone7 |
| net |
网络状态。wifi |
响应数据统一格式：code、msg、data。
array类型数据。通过list字段，保证data的Object结构。
分页类型数据。返回总条数，用于判断是否可以加载更多。
// object类型数据
{
"code":1,
"msg":"成功",
"data":{}
}
// array类型数据。
{
"code":1,
"msg":"成功",
"data":{
"list":[]
}
}
// 分页类型数据。
{
"code":1,
"msg":"成功",
"data":{
"list":[]
"total":"10"
}
}
列表类数据接口，无论是否要求分页，最好支持分页，pageSize=Integer.Max即可。
统一使用String类型。某些情况，统一使用String可以防止解析失败，减少类型转化操作。Boolean类型，1是0否。客户端处理时，非1都是false。
if("1".equals(isVip)){
}else{
}
status类型字段，从1+开始，区别Boolean的0和1。“0”有两种含义，（1）Boolean类型的false，（2）默认的status
上传/下载，参数增加文件md5，用于完整性校验（传输过程可能丢失数据）。
缩小单位保存数据，如：钱以分为单位、距离以米为单位。
客户端尽量不处理逻辑
客户端不处理金额
客户端参数校验规则可以通过接口返回，同时提供默认规则，接口不通则使用默认规则。
图片文案等，与校验规则类似，通过接口返回，并提供默认。
列表界面
/ 静态列表
{
"name": "张三",
"sex": "男",
"age": "20岁",
"nickName": "小张"
}
// 动态列表
{
"userInfos":[
{
"key":"姓名",
"value":"张三"
},{
"key":"性别",
"value":"男"
},{
"key":"年龄",
"value":"20岁"
},{
"key":"昵称",
"value":"小张"
}]
}
保护API的关键在于确保您充分了解威胁模型以及防御方式:
1）、平面隔离，确定接口所属平面，且平面已清晰隔离等。
2）、安全传输，安全传输是否已默认启用，相关算法、套件以及证书管理符合要求等。
3）、认证，默认账户公开，强口令策略，防暴力破解机制以及会话管理机制等
4）、鉴权，确保所有接口都已鉴权，不存在横向和纵向越权问题，不存在直接对象引用问题等。
5）、敏感数据和隐私保护，敏感数据均需要加密存储及传输，加密算法符合要求，文件权限控制得当。
6）、web安全，如果是WebApi接口，需要考虑覆盖web安全相关内容，如文件上传下载、输入编码输出校验、参数服务端校验等。
7）、接口Fuzz，对于接口需要从传输层、应用层分别考虑协议的Fuzz，包括应用层API接口Fuzz
8）、泛洪攻击，从传输层、应用层以及鉴权未鉴权消息角度分别考虑DOS、DDOS攻击风险
9）、安全日志，管理操作需要记录日志。
10）、业务逻辑安全，除了基础的安全之外，还要考虑接口业务逻辑上的安全设计是否合理，是否可能被绕过；重点关注登陆、忘记密码、重置密码等高危操作。
11）、WebServer配置安全，如果是web服务，需要考虑容器的安全配置，可使用工具扫描。
12）、源码安全，测试过程中结合接口源码，覆盖安全功能点，主要关注自研接口代码。
全部接口版本是否统一：
所有的接口都用相同的版本号：这样要发一个APP新版本就统一修改版本号，好修改，但是如果想修改其中一个接口的版本号就不行了。
每个接口的版本号可以不一样：这样比较灵活，建议这样做。
因为已经好多年没有做过服务端了。下面的见解如果有错误，希望指正。
1、每个接口逻辑里 加if 判断（不建议）
接口URL：api.xxx.com/api?version=v1&..
if (version == ‘1.5.0’) {
do_something
} else if (version ==‘1.4.0') {
do_something
}
优点：实现简单
缺点：不同版本的逻辑都在一个方法里，在于容易造成代码混乱，不利于维护。
2、不同的文件夹
相当于每个接口版本都是一个独立的项目。放到服务器的独立文件夹里。
例如：
接口URL：api.xxx.com/v1.0/xxxx.php
文件夹位置：Controller/V1.0/
-----------------/xxxx.php
文件夹位置：Controller/V2.1/
-----------------/xxxx.php
优点：版本逻辑分开维护。看url就能知道哪个版本。删除多余版本 不用修改代码。
缺点：同个接口不同版本 文件是重复的。并且 如果有个接口前几版就有问题，一直遗留到现在，就需要改好几套一样的代码。
3、不同版本 用不同的方法 ：
类似：
接口URL：api.xxx.com/v1.0/xxxx.php
复制代码
class XXXX{
public functionV1_0() { }
public functionV2_0() { }
}
java或者C# 都有路由配置，可以用路由配置不同版本的URL跳转到不同的方法里。
4、用继承的方式
“一瓶真情”在评论中回复：采用继承的方式，既可以利用之前的接口代码，又可以采用override的方式修改部分接口的实现。
这样是可以的。但是如果你上个版本（也就是父类）修改了代码，就会影响后面的所有版本。
在线上有bug或者需求变更的时候 很可能会修改基类。
5、部署到不同的服务器
6、混合使用
服务端的几种方法混用：
6.1、第3种和第4种方法一起用。先用继承，如果新版本和以前的版本无法复用，就用路由设置新的方法。
6.2、第1种方法和第3中方法一起用，简单的小改动用 第1种，加个if判断。改动较大的用 第3种，新开个方法。
合并接口。一个页面一个接口
字段简写
无用字段清理
图片裁剪
局部刷新。页面需要的数据，可以用前一个页面带来。
预加载
接口描述：用户登陆成功后，或进入首页时会获取一次用户信息。