嗯其实又是一篇早就写了的碎碎念, 在我的 simplenote 里躺了有一年了。也发出来充数吧，好显得我并没有把这个博客弃坑…
GraphQL 出来的时候似乎有老司机说它会“重新定义后端”，当然我们心里知道这实际上是重新定义了重新定义。综合官方文章来看，它要解决的问题都很明确 —— 我认为在 HTTP 1.1 时代它是很有工业价值的。然而它并非唯一的解决方案，RESTful API + HTTP/2 就是一种不错的备选。
一个对比 不一定对
细粒度请求的开销
Fetching complicated object graphs require multiple round trips between the client and server to render single views. For mobile applications operating in variable network conditions, these multiple roundtrips are highly undesirable.
这是 HTTP/2 要解决的问题。自 SPDY 作为先锋试水之后，HTTP 2 已标准化。其不仅解决了首部开销、多路复用等 HTTP 1.1 面临的问题，还做到了完全向后兼容。主流 Web Server （Apache httpd、Nginx 等）均已实现或计划实现 HTTP 2 的支持。所以在 H2 得到推广应用可以预期的背景下，细粒度请求的问题将是有解的。
字段不可选
Invariably fields and additional data are added to REST endpoints as the system requirements change. However, old clients also receive this additional data as well, because the data fetching specification is encoded on the server rather than the client.
这个实际上是一种字段协商的需求，可以通过 HTTP API 首部添加 X-Accept-Fields 之类的方法解决。
另外按照 RESTful API 的设计风格，资源应该倾向于细粒度的。如果粒度够细，似乎也不用多一个字段少一个字段地斤斤计较了。
标识弱类型
REST endpoints are usually weakly-typed and lack machine-readable metadata.
如果资源对应的是细粒度的 API，那么 URI 中能出现的只有资源的标识而已。似乎区别标识的类型并没有很大的意义？
一个想法 不一定对
我觉得 GraphQL 在解决 Facebook 自己的需求层面自然是有其实用意义的，但它并不适合作为一个通用解决方案或作为长期的标准。原因无外乎和很多资源查询语言一样 —— 它造了 HTTP 的轮子。
HTTP 无状态、以 URI 定位资源是有其道理的，针对这个特点可以非常容易实现对应用层透明的缓存。而 GraphQL 重新定义了资源的定位方式，相应的空缺需要重新补上。
当然，GraphQL 本身如果作为数据查询的 DSL，和 React.js 等结合将会很大提高前端开发的清爽度。实质上把 GraphQL 翻译成标准 RESTful API 访问是可行的。当 HTTP 2 得以广泛应用的一天，F2E 圈也许可以透明地将 RESTful API 策略放在 GraphQL 编译器的后面。而服务器端仍然能利用 RESTful API 的优势。
其他顺手搜到的资源
json:api 非常类似 Linked Data 应用的一种表现层标准。