@winglight2016
完全不是一回事，loopback 是封装了 参数校验、对数据库增删改查、消息推送 等常用功能的 套件，
和 Spring Cloud 类似，都是要自己写代码去实现接口的，最多能帮你自动生成一些简单的 CRUD 接口，
但这种代码基本上不能直接满足需求，还是要二次修改后才行，而且也基本在新增时用一次，后续接口都改动很大了，
去合并新生成的简单 CRUD 代码反而很麻烦，还不如直接改来得快。

APIJSON 是不需要后端写代码就能实现 从路由到数据库 的完整 API，
前端改变 JSON 参数，后端动态生成的 SQL 也会跟着变，
完全是前端自由灵活地定制后端的增删改查，
而且支持查任何数据库已有的表和字段、定制后端返回的任何组合与嵌套的 JSON 结构。

后端有 Java, C#, PHP, Node 的实现类库及 Demo，
前端有 Android, iOS, JavaScript 的 Demo。
https://github.com/TommyLemon/APIJSON

源码、文档、部署、视频 也都有
http://apijson.org/

可以试试 APIJSON， 它基于 SpringBoot，
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

i.v2ex.co/ez1DB9F0.png

i.v2ex.co/xLs9gX1e.png


通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
github.com/TommyLemon/APIJSON

目测是声明与引用顺序的问题，把 Rectangle 和 Circle 分别单独写成一个文件试试

Gson 也差不多：
```java
List<Person> people = gson.fromJson(jsonData, new TypeToken<List<Person>>(){}.getType());
```

FastJSON 很方便：
```java
List<Person> people = JSON.parseArray(jsonData, Person.class);
```

不支持 Class<Type>.class 就是因为 Java 为了兼容 1.4 及以下的 JVM，
实现时用的是 泛型擦除 方式，只能在运行前静态检查类型，
编译通过后 Type 就换成 Object 了，只能强转获取。
这个你看下 ArrayList 的源码就知道了，
里面是用 Object[] elementData 来存列表数据的，
get(int position) 内 return 的时候强转：
```java
public E get(int index) {
if (index >= size)
throw new IndexOutOfBoundsException(outOfBoundsMsg(index));

return (E) elementData[index];
}
```

@mmdsun id 在 1w 个以上可能会导致缓冲区溢出，这时就需要分批处理了

@stdying 涉及传感器的最好不要用插件，尤其是浏览器插件，可能会缺少权限，或者驱动有问题。

拆分 package，然后 gradle 执行打包时对应的 package，这样可以用一个工程打出不同包名的多个 APK。

如果真的就是同一个 APK，那除了判断配置跳到不同界面应该没有别的方法了。
具体实现可以是原生多套 Activity、内嵌多套网页、多套插件（类似 UC 浏览器的阅读插件等）

UPDATE 表名 SET 字段名=字段值 WHERE rowguid IN(rowguid1, rowguid2, rowguid3)

@TommyLemon
既然 a 表很大，可以拆分 SQL，在应用层 JOIN：
```sql
select * from a where a.go=2 limit 10
```
取出 a 的所有 id: [1,2,3...]，然后：
```sql
select * from b where id IN(1,2,3...)
```

@TommyLemon 最好还是自己在生产环境排除干扰后多次反复试验，哪个快用哪个

EXPLIAN 给出的执行过程是不一样的，第二个多了一个临时表的 SELECT，所以快不快和数据量有关

查询 1 的 from 是 form a ?
```sql
select a.*,b.* left join b on a.id=b.id where a.go=2 limit 10
```

@Cbdy
请用依据来说明为什么是“半吊子的设计”，我洗耳恭听，谢谢。
这些实实在在的优势，无论是从 在线体验工具、文档与源码、客户端 App Demo 上都能看出来。

@Livid @msg7086

在不相关的帖子下回答才是硬广吧，对读者有帮助的回答就是有意义的。
V2EX 作为一个技术社区，开诚布公、有理有据地讨论技术问题，
不灌水，不言语攻击，不做任何违反法律和道德的事情，
又有什么不妥呢？

@rockyou12
生成静态代码肯定是不可能完全切合业务需求的，还得改造，后续也得继续维护。
维护一段时间后，代码已经发生了很大的变化，整合生成的代码还不如直接改方便。

所以 APIJSON 就不是生成静态代码这个思路，而是
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

前端改变 查询 的 JSON 参数，
就会生成不同的 SQL，
后端代码不需要做任何改动；

后端改变数据库中 增删改 的校验规则，
就会加载新的规则来校验，
后端代码还是不需要做任何改动。

自动化的 JOIN 用起来也非常方便，不需要后端写代码，直接前端传的 JSON 参数加一行
"join": "</User/id@" // LEFT JOIN User ON User.id = XXX.userId

这样就能很好地切合业务需求了。

创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
github。com/TommyLemon/APIJSON