Linuxeden开源社区作者 ，译者 李勇
在法国巴黎API日这上，Arnaud Lauret 谈了GraphQL和RESTful HTTP API各自的优点和缺点。从他的总结可以看出，是使用场景决定了具体该使用哪种API，而且这两类API在实际使用中会有很多的权衡考虑。
GraphQL是一种API查询语言，是由Facebook创建并最终开源的，可以认为是REST的一种替代品。来自AXA Banque的API架构师Lauret给出了一些可对二者进行比较的切入点：
- GraphQL能够通过一次查询得到所有需要的数据，从而减少网络跳转的次数。
- GraphQL采用所见即所得模型，这样客户端代码不易出错。
- RESTful HTTP通过使用状态码和HTTP verb，提高了结果的一致性和可预测性。
- 借助超媒体，在用户使用API时可以“发现”资源间的关系，这简化了RESTful用户的具体实现。
- HTTP实现了缓存机制而GraphQL还没有实现。
- GraphQL给用户提供了schema，这很有用，但是需要注意的是接口描述并非API文档。
Lauret认为GraphQL的主要优势是其使用的所见即所得(WYSIWYG)模型。也就是说，查询结果的结构是查询结构本身的精确映射，这样的话，用户在解排（unmarshal）响应的时候不容易出错。
他也解释了为什么GraphQL模型可以减少网络跳转次数。对RESTful HTTP来说，资源和子资源可能存在于不同的节点上，所以需要多个请求才能获取到期望的数据的情况就在所难免。但是GraphQL却可以在单次请求中获取到所有期望数据。实际上，一次只查询系统中的一种资源是有可能的。
虽然Lauret认为模型非常强大，但是他也解释了单端点方案可能带来的一致性和可预测性损失。相对于RESTful HTTP API，GraphQL不能正确使用HTTP verb会带来很明显的损失。举个例子，在使用RESTful HTTP时，当用户向资源发送了DELETE请求时，用户清楚这个操作是安全和幂等的，同时也清楚这个操作是用来删除资源的。
Lauret指出GraphQL缺少HTTP状态码会带来可预测性损失，HTTP状态码是人机都可读的。相关的例子如当不能找到资源时返回的404状态码，或者用户没有权限访问时返回403状态码等等。
REST充分利用了超媒体，也就是说通过遍历API，用户就可以发现链接和相关资源。这就消除了用户用于链接构建和给客户端返回资源关系等操作的需求。Lauret解释说因为GraphQL完全聚焦于数据，所以开发者会更加依赖于文档。
因为HTTP缓存已经是web架构的一部分，所以Laure强调HTTP RESTful API使用了这种标准的HTTP缓存，而GraphQL的用户则需要自己实现缓存机制, 这种额外的负担其实是可以避免的。
Lauret列出了GraphQL的最后一个优势，即提供schema，schema可以在运行时被获取到。当客户端决定可能的查询时，这非常有用。但是Lauret警告说接口描述不是文档，GraphQL不足以解决所有的API文档问题。
作为总结，Lauret认为没有通用方案，只要是对当前需求有利的方案都可以使用。他也提到，由于高级API所具有的共性，如果用户不善于使用某种API，那么他们其实不善于使用任何一种API。完整视频可以通过这里在线观看，关于该演讲的总结可以参考该篇博客文章。
查看英文原文：GraphQL vs REST: Things to Consider
转自 http://www.infoq.com/cn/news/2017/07/graphql-vs-rest