GraphQL和Fieldings REST约束

Question

在他dissertation，Fielding定义了一组规则，应符合REST API。

这包括除其他外以下规则：

• 客户端 - 服务器
• 无国籍缓存接口
• 统一合同（超媒体或HATEOAS，..）
• 分层系统

是否有可能满足GraphQL这些要求？

虽然点的客户端 - 服务器，无状态和分层系统很可能实现，我不知道该点缓存和统一的合同。

Answer 1

让我们通过Fieldings约束和检查GraphQL满足他们：

客户 - 服务器架构 - YES

GraphQL是（主要）的查询语言，从客户机到服务器指定的查询。

无国籍 - YES

对此进行详细here dicussed。 简短的回答是肯定的，GraphQL是无状态的，因为没有会话的概念和服务器并不需要任何额外的信息来处理请求。

缓存能力 - NO

这一个是棘手。从技术上讲，您可以在HTTP请求级别缓存GraphQL查询（如果您use HTTP）。但是，由于客户端可以查询对象和属性的任意组合，因此这种缓存的命中率可能很低，并且缓存的信息高度冗余。正因为如此，GraphQL开发者建议graph-based caching approach。然而，这种方法需要全局唯一标识符，介绍关于GraphQL规格之上的附加约束，即可疑类似于REST的“资源标识”的约束（见下文）。

另一种方法是推迟缓存到到GraphQL服务器提供数据的其他组件，但这是无关GraphQL本身。鉴于上述情况，我会说GraphQL请求默认情况下不可缓存。

分层系统 - YES

守备described分层架构作为一个......

...通过约束构件行为分级层组成 使得每个组件不能“看到”超出与他们正在交互的 的即时层。

您可以设置一个GraphQL服务器来转发请求到其他GraphQL服务器，而客户端不知道它。实际上，GraphQL服务器通常用作“前端后端”，用于汇总客户端不知道的其他服务的数据。这是一个分层系统。

接口/制服合同 - NO

这个约束通常通过四个子约束配制：

资源

• 鉴定 - NO

如上所述， GraphQL不提供统一的机制来识别资源ES。该GraphQL documentation状态：

HTTP通常与REST，它使用的“资源”为 核心理念有关。相比之下，GraphQL的概念模型是一个实体 图。因此，GraphQL中的实体不会被URL标识。经过交涉资源

• 操作 - （？）是

假设GraphQL的资源是数据对象，并转移JSON（或其他格式）是表示（而不是将整个GraphQL端点视为单个资源）。然后，将变异的JSON表示发送回服务器以更新对象是可能的。

• 自描述性消息 - NO

这一个是，在我看来，见仁见智（？）。何时是一个自我描述的信息？如果目标是通过客户端和服务器之间的任意引入的中间层“可以理解”，那么我认为GraphQL消息不是自描述性的。查询或变化的结构只在服务器模式的上下文中才有意义。可以从服务器请求此架构，但这会扩展单个消息的范围。

• 超媒体作为应用状态（HATEOS）的发动机 - NO

这一个是简单的。 GraphQL根本不支持链接的概念，链接是超媒体的前提和本质。 This article对这个主题有一些有趣的看法。

代码点播（可选） - NO

是从GraphQL服务器发送到客户端的所有数据被键入。没有支持的类型打算执行。表示动作的变异请求仅从客户端发送到服务器，而不是其他方向。当然，始终可以将代码作为文本发送，但这可能不是GraphQL的设计目的。

---

总之，GraphQL不符合所有REST要求。这可能不是有意的。它旨在解决由REST原理引起的一些问题，主要是客户端需要多次HTTP往返才能获取单个对象图，并反过来接收比实际使用的更多的数据。