前阵子在公司内部分享了GraphQL，今天抽空总结并补充一下：
目前项目开发比较流行的是前台后分离模式，后台提供接口，前台调用接口，接口书写遵循流行的RESTful API规范
- REST 由 Roy Thomas Fielding 在他2000年的博士论文中提出的。
- REST，即 Representational State Transfer(表述性状态传递) 的缩写。
- 如果一个架构符合 REST 原则, 就称它为 RESTful 架构
RESTful API 特点
- 每一个 URI 代表一种资源；
- 充分利用 HTTP 协议本身语义；
- 客户端和服务器器之间，传递这种资源的某种表现层；
- 客户端通过四个 HTTP 动词，对服务器器端资源进行操作，实现 " 表现层状态转化 " 。
RESTful API 缺陷
- 一个接口仅操作单一资源
- 各个资源是独立的，完成一个页面需要调用多个接口
- 数据冗余，灵活性差
- 需专门维护文档 (v1, v2)
有时候打开某个页面，我们需要调用多个接口。
有时候我们不需要的字段后台也给我们返回了，这是由后台控制的。
而GraphQL可以完美的解决上面的问题
GraphQL是….
- Facebook 2012年开发，2015年开源
- 应用层的API查询语言
- 在服务端的运行数据查询语言的规范 (我建议你先抽半个小时浏览下心里有个大概)
GraphQL的特点
- 强类型
- 单一入口
- 一个请求获取所有所需资源
- 内省系统
为什么叫GraphQL
图（Graph）是一种复杂的非线性结构，在图结构中，每个元素都可以有零个或多个前驱，也可以有零个或多个后继，也就是说，元素之间的关系是任意的。
使用GraphQL 注意的问题
- 性能问题 (请求少了，但查询多了)
- GraphQL 在前端如何与视图层、状态管理方案结合
- 安全, Limit, timeout N+1 查询
关于从规范里提炼的
- GraphQL是一种数据描述语言，而非编程语言，因此GraphQL缺乏用于描述数学表达式的标点符号。
- 注释只能用 # ，可以使用末尾的逗号提高可读性。
- GraphQL的命名是大小写敏感的，也就是说name，Name，和NAME是不同的名字。
- 一个文档可以包含多个操作和片段的定义。一个查询文档只有包含操作时，服务器才能执行。
- 如果一个文档只有一个操作，那这个操作可以不带命名或者简写，省略掉query关键字和操作名。
下一篇 实战
