统一返回结构

避免混乱不一致的返回结构，包括分页场景、直接return场景等

使用统一封装结构体实现

包括后续traceID等

type PageResponse struct {
  Result     int         `json:"result"`
  Message    string      `json:"message"`
  Success    bool        `json:"success"`
  TotalCount int         `json:"totalCount"`
  Data       interface{} `json:"data"`
  PageNum    int         `json:"pageNum"`
  PageSize   int         `json:"pageSize"`
}

统一返回风格

确保返回风格一致

统一骆驼峰风格

统一骆驼峰命名风格，如 appName

类型一致，默认都是string，如 appName string、id string

ID特殊，使用ID

请求方式

区分方法，统一请求方式

微服务Restfull

非微服务：

Get方法，统一 ==> Url+Parm

Post方法，统一 ==> Post+Json处理

确保Get方法，不要既有参数又有json、又有body。

特殊场景除外：「有些业务URL参数带统一参数，比如国家、机型等；目的方便日志库检索」，Body里有业务属性。

但，这不是最佳实践，历史原因导致除外。

后端接口优先级

作为被依赖的主接口「如：其他requst需依赖该接口结果」的接口，需确保其执行效率

使用缓存等技术，确保往返耗时

「如不超过100ms」

默认值

需传参但未传参页面的默认返回结果

约定默认返回结果

部分页面需要携带上个页面的参数，假如不希望当前页面留空，可以约定在返回结果时，返回默认结果。

但这个不一定体验很好，后续权限划分后，用户看到的不一定是自己希望看到的

后续要考虑到权限区分、隔离。确保不同的人看不同的东西。订阅概念逻辑

前端传参但后端不能处理

防御性编程、验证入参

前后端实现的划分原则

需要依赖到实时数据获取的功能，通常后端实现，除非变化幅度非常小；否则前端需要实时拉取

后端实现场景：

1、用户数据展示时，行 显示自定义列的配置信息「需要实时更新、千人千面」「类似订阅模式」

前端实现场景：

1、国家、地区、城市数据「变化不大」

Get/Post

原则：

查询条件检查、原子操作、只查询不修改；使用Get、URL参数简单

如果条件复杂，不建议Get+body「中间传输环境容易被拦截、出问题或者不识别」、直接使用Post+Json、前后端处理都方便