认识达内从这里开始

随着互联网的不断发展，越来越多的软件被开发并发布到了互联网上，由于软件的运行环境的不同，在进行软件开发设计的时候，许多的编程接口也是需要进行不同的适配。今天，我们就一起来聊聊关于API接口的编程技术语言的一些知识，下面就开始今天的主要内容。

在法国巴黎API日这上，ArnaudLauret谈了GraphQL和RESTfulHTTPAPI各自的优点和缺点。从他的总结可以看出，是使用场景决定了具体该使用哪种API，而且这两类API在实际使用中会有很多的权衡考虑。

GraphQL是一种API查询语言，是由Facebook创建并最终开源的，可以认为是REST的一种替代品。来自AXABanque的API架构师Lauret给出了一些可对二者进行比较的切入点：

GraphQL能够通过一次查询得到所有需要的数据，从而减少网络跳转的次数。

GraphQL采用所见即所得模型，这样客户端代码不易出错。

RESTfulHTTP通过使用状态码和HTTPverb，提高了结果的一致性和可预测性。

借助超媒体，在用户使用API时可以“发现”资源间的关系，这简化了RESTful用户的具体实现。

HTTP实现了缓存机制而GraphQL还没有实现。

GraphQL给用户提供了schema，这很有用，但是需要注意的是接口描述并非API文档。

Lauret认为GraphQL的主要优势是其使用的所见即所得(WYSIWYG)模型。也就是说，查询结果的结构是查询结构本身的精确映射，这样的话，用户在解排(unmarshal)响应的时候不容易出错。

他也解释了为什么GraphQL模型可以减少网络跳转次数。对RESTfulHTTP来说，资源和子资源可能存在于不同的节点上，所以需要多个请求才能获取到期望的数据的情况就在所难免。但是GraphQL却可以在单次请求中获取到所有期望数据。实际上，一次只查询系统中的一种资源是有可能的。

虽然Lauret认为模型非常强大，但是他也解释了单端点方案可能带来的一致性和可预测性损失。相对于RESTfulHTTPAPI，GraphQL不能正确使用HTTPverb会带来很明显的损失。举个例子，在使用RESTfulHTTP时，当用户向资源发送了DELETE请求时，用户清楚这个操作是安全和幂等的，同时也清楚这个操作是用来删除资源的。

Lauret指出GraphQL缺少HTTP状态码会带来可预测性损失，HTTP状态码是人机都可读的。相关的例子如当不能找到资源时返回的404状态码，或者用户没有权限访问时返回403状态码等等。

REST充分利用了超媒体，也就是说通过遍历API，用户就可以发现链接和相关资源。这就消除了用户用于链接构建和给客户端返回资源关系等操作的需求。Lauret解释说因为GraphQL完全聚焦于数据，所以开发者会更加依赖于文档。

因为HTTP缓存已经是web架构的一部分，所以Laure强调HTTPRESTfulAPI使用了这种标准的HTTP缓存，而GraphQL的用户则需要自己实现缓存机制,这种额外的负担其实是可以避免的。

Lauret列出了GraphQL的最后一个优势，即提供schema，schema可以在运行时被获取到。当客户端决定可能的查询时，这非常有用。但是Lauret警告说接口描述不是文档，GraphQL不足以解决所有的API文档问题。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益！