完爆FacebookGraphQL，APIJSON全⽅位对⽐解析（⼆）-权
限控制
相关阅读：
⾃APIJSON发布以来，不断有⽹友拿来和Facebook开发的GraphQL对⽐，甚⾄不少⼈声称“完爆”APIJSON。
然⽽事实正好相反，本系列博客将以⼤量真实依据来证明，APIJSON“完爆”GraphQL！
APIJSON的⼝号是:
后端接⼝和⽂档⾃动化，前端(客户端) 定制返回JSON的数据和结构！
APIJSON的简介：张国荣死亡时间
APIJSON是⼀种为API⽽⽣的JSON⽹络传输协议。
为 简单的增删改查、复杂的查询、简单的事务操作 提供了完全⾃动化的API。
能⼤幅降低开发和沟通成本，简化开发流程，缩短开发周期。
适合中⼩型前后端分离的项⽬，尤其是互联⽹创业项⽬和企业⾃⽤项⽬。
通过⾃动化API，前端可以定制任何数据、任何结构！
⼤部分HTTP请求后端再也不⽤写接⼝了，更不⽤写⽂档了！
前端再也不⽤和后端沟通接⼝或⽂档问题了！再也不会被⽂档各种错误坑了！
后端再也不⽤为了兼容旧接⼝写新版接⼝和⽂档了！再也不会被前端随时随地没完没了地烦了！
特点功能
在线解析
⾃动⽣成⽂档，清晰可读永远最新
⾃动⽣成请求代码，⽀持Android和iOS
⾃动⽣成所有JavaBean，⼀键下载
⾃动管理与测试接⼝⽤例，⼀键共享
⾃动校验与格式化JSON，⽀持⾼亮和收展
对于前端
不⽤再向后端催接⼝、求⽂档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可⼀次获取任何数据、任何结构
能去除重复数据，节省流量提⾼速度
补血的东西
对于后端
提供通⽤接⼝，⼤部分API不⽤再写
⾃动⽣成⽂档，不⽤再编写和维护
⾃动校验权限、⾃动管理版本
开放API⽆需划分版本，始终保持兼容
⽀持增删改查、模糊搜索、正则匹配、远程函数等
⾃动化权限控制(APIJSON特有)：
GraphQL【没有】提供权限控制的功能，甚⾄在官⽅⽂档和源码⾥连如何实现的教程也⼏乎没有，
⽽仅仅提及了如何在你的【业务代码】⾥去【⼿动】实现⼀个【所属⼈】⾓⾊的权限控制。
⾼亮的这⾏代码
if (context.ur && (context.ur.id === post.authorId))
复制代码
就是在后端⼿动写的postType中，⼿动加的resolve函数⾥，加上这么⼀个urId关系判断。
也就只能实现当查询postType对应的表时，只有post⾥的authorId和来访ur的id相等时，才返回查到的结果。
下⽂中善意地提⽰了你，不要写死在某个Type的resolver函数中，
⽽是应该封装到⼀个postReponsitory，⾥⾯放⼀个getBody的函数，内部再实现这个判断并return。
这样不仅逻辑清晰，还能在别的Type中⽤到postType时（例如urType嵌套postType）可以复⽤。（PS: 这个⽂档中没说，我帮它说了）
但即便你花了时间去新写⼀个类、再新写⼀个函数，做了这个封装，那也只是postType能复⽤⽽已，
其它的humanType，droidType，queryType等⼀⼤堆Type不都还是得⼀个个写？
⽽且当今的互联⽹应⽤中，不管是⽹站，还是移动端App，稍微复杂⼀点的都不只是【所属⼈】这么⼀个⾓⾊，
其中⼤部分，尤其是社交应⽤，都包含 【联系⼈】、【朋友圈】这两个⾓⾊。
当然，所有具有账户登录的应⽤，都可以分【已登录】、【未登录】这两种⾓⾊。
既然GraphQL不提供权限控制功能，那就只能⾃⼰根据每种⾓⾊⼀个个写了。
按照以上唯⼀⼀个官⽅⽰例，我们对应所有⾓⾊的判断应该是：
未登录：
if (context.ur == null || context.ur.id == null || context.ur.id <= 0) {
return post.body;
}
return null;
复制代码
已登录：
if (context.ur && context.ur.id && context.ur.id > 0) {
return post.body;
}
return null;
复制代码
朋友圈：
var urId = context.ur == null ? null : context.ur.id;
var contactIdList = context.ur == null ? null : actIdList; //联系⼈id列表
if ((urId && urId === post.authorId) || (contactIdList && contactIdList.indexOf(post.authorId) >= 0)) { return post.body;
}
return null;
复制代码
联系⼈：
var contactIdList = context.ur == null ? null : actIdList; //联系⼈id列表
if (contactIdList && contactIdList.indexOf(post.authorId) >= 0) {
return post.body;
}
return null;
复制代码
所属⼈：
if (context.ur && (context.ur.id === post.authorId)) {
return post.body;
}
return null;
复制代码
仅仅⽤GraphQL实现查询postType这⼀个Type对应的⾓⾊权限控制，居然就要写这么多判断代码！
假设我们数据库有20张表（实际很轻量级的应⽤才只有这么少的表），对应写了20个Type，那就是 20*5 = 100 个判断仅仅是判断⾓⾊权限的代码就⾄少有 20*(4 + 4 + 6 + 5 + 4) = 460 ⾏
⽽APJSON提供了⾃动化的权限控制，可以细分到 每张表、每⾏记录、每种⾓⾊、每种操作 的控制粒度！
⽽且每张表只需要写3⾏代码就能配置各种⾓⾊的增删改查的权限！
我们⽤APIJSON来操作⼀张表，例如⽤户表Ur，代码写3⾏就够了：
//注册表并添加权限，⽤默认配置
@MethodAccess
public class Ur {
//内容⼀般仅供表字段说明及Android App开发使⽤，服务端不⽤的可不写。
}
//DemoVerifier内添加权限
ACCESS_MAP.put(SimpleName(), getAccessMap(Annotation(MethodAccess.class)));
复制代码
或者可以再定制下POST请求的⾓⾊权限：
@MethodAccess(
POST = {UNKNOWN, ADMIN} //只允许未登录⾓⾊和管理员⾓⾊新增Ur，默认配置是 {LOGIN, ADMIN}美卡犬图片
)
public class Ur {}
复制代码
然后运⾏下Server⼯程就可以请求了：
请求：
{
"Ur": {
"id": 82001
}
}
复制代码
返回：
{
"Ur": {
"id": 82001,
"x": 0,
"name": "Test",
"tag": "APIJSON Ur",
避孕套品牌排行榜
"head": "static.oschina/uploads/ur/19/39085_50.jpg",
"contactIdList": [
82004,
82021,
70793
],
"pictureList": [
"/images/icon_weibo_24.png"
],
"date": "2017-02-01 19:21:50.0"
},
"code": 200,
"msg": "success"
}
复制代码
复制代码
我们再试试APIJSON的⾃动化权限控制到底 能不能达到期望、会不会被绕过 吧。
查询⽤户开放信息Ur：
请求成功：
{
"Ur": {
"id": 38710,
"x": 0,
最专一的星座
"name": "TommyLemon",
英语电子邮件格式>玫瑰绳缘"tag": "Android&Java",
"head": "static.oschina/uploads/ur/1218/2437072_100.jpg?t=1461076033000", "contactIdList": [
82003,
82005,
90814,
82004,
82009,
82002,
82044,
93793,
70793
],
"pictureList": [
"static.oschina/uploads/ur/1218/2437072_100.jpg?t=1461076033000",
"/images/icon_weibo_24.png"
],
"date": "2017-02-01 19:21:50.0"
},
母绵羊"code": 200,
"msg": "success"
}
复制代码
