接口风格

不太喜欢 RESTful，因为不够灵活。get、post只是传递数据的方式，根据数据要求而定，而不应该和增删改查绑定死。

比如查询为啥只能是get？太死板了，我查询条件特别多，而且复杂，那么我为啥不能用post来提交？

一个资源为啥只能有 get（获取）、post（添加）、put（修改）、delete（删除）四种？
而实际情况是，获取（get）就细分为多种：

根据ID获取一条记录（查询、修改用）
获取全部数据（数据字典用）、
分页获取数据。

都用get的话，如何区分？还有物理删除、逻辑删除，按照分类删除数据，删除整个部门（包含子部门）等。

每天都要想，咋弄，很累呀有没有？

当然也是有优点的，比如，，，，好吧，有优点我们学过来就好。

我比较喜欢 GraphQL 的方式，只是不太理解，为啥是在前端做格式设定，然后把整个设定传递给后端。

我们为啥不能先做好格式设定，存放在后端，并且做一个编号。

前端使用的时候，传递编号和需要的数据即可，没有必要每次都传递格式设定呀。

自己动手丰衣足食

既然没有符合想象的，那么就自己设计一套好了。

后端 API.png

先只考虑单表的情况，也就是先实现单表的增删改查。

一个模块、一个表、一个服务，可以作为最基础的单位，然后内部分为多个action，实现增删改查的功能。

然后就是 model （也就是实体类），为了便于复用，model 的在模块内是单独设置的，然后action 可以选择适合的 model。
也就是说一个服务里面可以有多个model。虽然多数情况一个 model 就够了，

这样可以实现按需索取的功能，也就是说，表里面有一百个字段，而前端只需要十个字段，那么我们可以设置一个包含十个字段的model，而不是一个包含一百个字段的model。

举个例子

{
  "moduleId": 120,
  "moduleName": "角色管理",
  "actions": {
    "10": {
      "actionName": "添加角色",
      "kind": "model-add",
      "model": "10-role"
    },
    "20": {
      "actionName": "修改角色",
      "kind": "model-update",
      "model": "10-role"
    },
    "30": {
      "actionName": "删除角色",
      "kind": "model-delete",
      "model": "10-role"
    },
    "40": {
      "actionName": "获取角色",
      "kind": "model-get",
      "model": "10-role"
    },
    "50": {
      "actionName": "查询角色",
      "kind": "list-pager",
      "model": "10-role"
    },
    "60": {
      "actionName": "获取全部数据",
      "kind": "list-all",
      "model": "10-role"
    }
  },
  "models": {
    "10-role": {
      "tableName": "r_role",
      "idKey": "roleId",
      "cols": {
        "roleId" : "编号",
        "roleName": "角色名称",
        "remark": "角色介绍"
      },
      "pager": {
        "pagerTotal": 100,
        "pagerSize": 5,
        "pagerIndex": 1,
        "orderBy": { "roleId": false }
      },
      "query": {
        "roleName":[401, 402, 403],
        "roleId":[401]
      }
    }
  }
}

这样就比较方便了，前端提交 moduleID（服务ID），actionID，还有 body 就可以了。
接口统一，结构统一，只需要考虑 body 如何组织就可以了。

是不是很方便了？