Restful和GraphQL，该怎么选择？

我在写dragonfly的web组件时，遇到一个技术决策：要不要支持GraphQL？

Restful肯定是必须支持的，哪怕开发人员所设计的Restful API，形式上几乎都不合格，都是Roy Fielding博士批判的伪Rest，但我还是提供了Get, Post, Put, Delete, Head, Patch六种方法的完整支持。

而GraphQL就很难办了，虽然Meta(Facebook)把它弄出来，愿景很大，有取代Restful之势。但从我的角度看，很鸡肋。

首先，GraphQL是一种Data-Driven或者Data Oriented Development，从前端到后端，眼里都是透明的数据。然而大多数应用，都是Business-Driven，要处理复杂的业务，而不是简单对数据的CRUD，所以应用场景非常有限。

其次，所谓的Overloading问题，就是前端想要那几个字段，后端只需要返回那几个字段即可，避免“过度加载”。其实这根本不是个问题，后端完全可以通过Filter过滤掉不需要的字段。

最后，所谓的嵌套问题，避免多次请求。这也是个伪问题，后端可以根据前端业务需要设计对应的API和数据结构。

GraphQL带来的便利，与它的复杂度（学习成本），性能开销相比，是否划算？我认为不划算。大家如果懂点编译的话，不妨试着去写个GraphQL解析器，就知道多麻烦了。

所以最终，我在RESTFUL API上提供了一点有限的GraphQL Query支持，前端通过GraphQL Query语法指定需要哪些字段，Web组件通过预编译和过滤，尽量不损失性能为前提，达到“前端说要什么就给什么”的效果。

所以，所谓设计，其实本质就是Tradeoff，权衡、妥协、折中。

whale: A JSR330 Based Java DI Framework