1.6.6 GraphQL替代了什么

GraphQL的诞生，主要是有针对性地解决RESTful API的问题。而RESTful API好的方面，比如每个资源都有ID、资源的多种表达、标准化的请求、无状态通信、非常好的兼容性等，在GraphQL中都有很好的继承和发展。一般把GraphQL作为RESTful API的替代技术。

正是借助上面提到的GraphQL的种种优点，让开发者可以尽情地设计所需的数据结构，更多地关注数据实体之间的关系，同时可以在各种数据上自由地查询和组合。而API设计也可以真正摆脱视图（View）的束缚。

从MVC大行其道开始，很多开发者非常习惯从视图的角度来设计API和数据模型（Model），开发者往往会先想好，这个网页或者某个手机移动应用的窗体需要什么数据，然后设计一个或多个API来准备这些数据。比如做一个用户的页面，就设计一个RESTful API，用/user/:id返回需要的数据。但是视图是最善变的，产品经理未必总有心修改系统的数据模型，但对视图的想法肯定会是层出不穷的。比如可能会提出给用户页面添加最近发帖的列表、好友列表等，可能有一天还会提出把发帖列表删去，然后换成显示最近访问过的帖子。如果API和数据模型总是跟着视图改来改去，这对前后端系统都是一种伤害。

GraphQL可以让视图的构建者或者说是API的调用者不需要关心API背后的实现细节，同时API的提供者也不需要关心调用者那边视图的组合方式。比如，现在如果大家开发GitHub的应用，就会发现GitHub最新版API已经使用GraphQL来代替RESTful API了（https://developer.github.com/v4/）。

这套新的GitHub API不单单给GitHub官方客户端使用，也同时开放给第三方公司或者个人开发的客户端使用，绝大多数客户端并不知晓GitHub的内部如何存储数据，它们只关心自己独到的用户界面设计，每一个视图都会有自己特殊的数据需求。也正是因为使用这套API，我们开发应用的时候可以不关心GitHub的实现细节，只需要考虑资源之间的关系。而GitHub方面也无须关心各种应用客户端具体如何构建视图，它只要保证能按客户端所定制的字段提供数据就可以了。这里不是给GitHub网站打广告，把它列在这里，主要是因为这套API也是学习GraphQL的好资料。