提交的接口

url 的格式

【method】/api/:moduleId/:actionId/:dataId

• method
  这个没啥要求，不需要 body 就用 get，需要 body 就用 post。
  可以支持其他的，只是没啥作用。

• moduleId
  模块ID，原来想直接用serviceId的，但是发现这样做的话数量太多，容易懵逼，所以还是用一个模块来做一个分组，这样API接口的数量，看起来就不会太多。

• actionId
  动作ID，类似于 RESTful 里面的get、post、put、delete等，
  也类似于ASP.net MVC 里面的action。
  没有使用 RESTful 的方式，是因为总感觉灵活度不够。这里使用ID（也可以是其他标志）可以更灵活一些，摆脱一些束缚。

• dataId
  记录的主键的值，用于获取（get）记录，删除记录，修改记录等。
  可以作为一个资源的唯一标志。

举例

【post】/api/100/10  // 添加
【post】/api/100/20/1  // 修改
【get】/api/100/30/1  // 删除
【get】/api/100/40/1  // 获取记录（model）
【post】/api/100/50/1  // 分页+查询，获取记录集
【post/get】/api/100/60/1  // 获取记录，可以查询

如果感觉“魔数”不好看的话，可以改成单词：

【post】/api/user/10-add  // 添加
【post】/api/user/20-update/1  // 修改
【get】/api/user/30-delete/1  // 删除
【get】/api/user/40-get/1  // 获取记录（model）
【post】/api/user/50-pager  // 分页+查询，获取记录集
【post/get】/api/user/60-all  // 获取记录，可以查询

actionId，也采用数字，是因为懒得起名字了，起名困难症呀。

body的格式

这个根据申请的类型有所区别。其中获取、删除只有get，没有post方式，也就是没有body的格式。

添加、修改

按照需求设置字段名和字段值

{
  name:"这是名称",
  age:"18"
}

表单数据

分页和查询

{
  pager: {
    pagerIndex:2,
    pagerSize:20
  },
  query: {
     name: [401, "jyk"]
  },
  useCount: false
}

分页 + 查询

• pager
  提交两个参数，一个是第几页的数据，一个是一页多少条记录。

• query
  提交查询条件

• useCount
  是否需要统计总记录数。这个是出于性能的考虑。

接收的格式

还没想好具体的格式，先弄个code吧，似乎大家都是这么弄的。
这个code仅仅表示业务逻辑，和其他无关。
其他的嘛，model表示一条记录，list表示列表，pager表示分页信息。
其他待定，也许应该加一个msg，出错的时候放描述错误信息。

添加

返回新记录的ID值

新记录ID

修改和删除

返回影响的行数，如果为 1 ，说明改了一条（或者删除一条），如果为 0 说明没找到记录。

修改和删除

获取

返回model

model

查询

返回记录集合

获取全部数据

分页

返回记录集合以及分页信息

分页获取记录