标准REST技术中的GraphQL替代方案

Question

什么是Facebook的GraphQL的确切或接近的替代品？

有一些文章给出了GraphQL的缺点( pro是骗局)：

1. https://www.imaginarycloud.com/blog/graphql-vs-rest/
2. https://blog.logrocket.com/why-you-shouldnt-use-graphql/
3. https://www.robinwieruch.de/why-graphql-advantages-disadvantages-alternatives
4. https://www.moesif.com/blog/technical/graphql/REST-vs-GraphQL-APIs-the-good-the-bad-the-ugly/

主要的是，它还不是静止的行业标准。

如何使用REST、JSON其他库获得GraphQL中的功能？

特别是对于查询部分，是否存在类似的查询语言？

这个问题不是GraphQL是好是坏，而是与REST最接近的是什么。对GraphQL和REST生态系统都有深入了解的人，可以与之相提并论。谢谢

Answer 1

让我们从GraphQL是什么开始，因为这可能需要较少的时间：

GraphQL是一种查询语言，类似于用于数据库的SQL，用于告诉服务器客户端希望从服务器接收哪些字段/元素/属性。与SOAP类似，它使用单个端点接受POST或GET请求。除了GraphQL，您还可以使用RestQL和法尔科，它们或多或少地推进到相同的方向。

在REST体系结构中，只有资源。当前资源的状态以协商后的表示格式表示，即发送方和接收方，可以理解，因此REpresentational状态转移或REST简称为REST。REST附带了一些约束条件，当遵循这些约束时，应该可以保证互操作性，同时允许服务器在未来发展，而不必担心客户机崩溃，因为该体系结构中的每个参与者都将按照已知的标准化格式操作，而不是使用特定于该API的标准格式。

虽然REST通常使用HTTP作为其传输层，但许多针对REST的问题实际上要求HTTP内容，因此混淆了两者。REST的设计与传输层无关，因此也可以使用HTTP以外的其他传输协议。吉姆·韦伯在2011年做了一次很棒的演讲，他说HTTP只是一个应用协议，其域是通过网络传输文档。因此，如果您在浏览器或任何其他(一般的) HTTP客户端中发出请求，只需向服务器发送一个文档，并作为响应得到一个文档。这是HTTP。它只会发送文件。HTTP的操作就是为此而量身定做的.我们仍然使用HTTP从文档管理中派生业务规则。因此，我们得出的任何业务规则都只是实际文档管理的副作用。

HTTP和REST都不关心什么资源表达式。甚至索赔那个休息不应该有类型化资源。如果您将其与使用同一个客户端(浏览器)查找当前证券交易所的Web进行比较，请收集有关您喜爱的汽车型号或未来几天天气预报的信息。所有这些信息都是用相同的媒体类型HTML表示的，而且我们人类仍然可以理解它，因为浏览器很擅长在画布上呈现这样的有效负载，所以我们不必处理类似于SGML/XML的语法。

由于REST资源没有对客户端有意义的具体类型，因此很难想象客户机如何指示服务器返回资源的属性。因此，在GraphQL中，客户端必须对掌握的资源及其类型有一些预先的了解，这是我已经谈到过的这里。

不过，Fielding这样回答了将REST和GraphQL结合在一起的一种方法：

客户端可以向REST服务发布以创建一个GraphQL查询的资源，然后利用REST…的所有优点获取该资源。(来源)

然而，正如你所要求的那样。REST在一个简单的前提下运行，服务器应该教客户机它能做的一切，并且必须知道如何提出进一步的请求。在Web上，通过广泛的HTML支持，服务器为客户端提供了一组链接，它可以请求进一步的内容，或者返回包含<form>...</form>部分的HTML表示。这就是Web服务器如何教会客户端将请求发送到哪里(目标URL)、使用什么HTTP操作、在编组请求时使用哪种媒体类型(通常是隐式地表示为application/x-www-url-form-encoded)以及资源支持的属性的基本方式。我是哈特奥。我们使用超文本通过工作流驱动客户端，或者正如Jim通过域应用程序协议调用的那样，通过向它可以遵循的客户端提供选项，它的行为类似于基于文本的计算机游戏或网上商店结账。

那么，Web如何帮助接近GraphQL呢？服务器可以简单地以要返回的部分的形式提供选项。假设有一个复选框，该复选框包括资源所拥有的每个字段，这些字段可以被选中，如果选中，则会出现在响应中。根据资源所具有的属性的数量，服务器也可以建议某些分组。这就消除了外部文档或预先知识的必要性，并且取决于客户机如何处理响应，这也是向客户端提供关于客户端选项的一种未来证明方法。

除了HTML表单之外，您还可以使用一些基于JSON的JSON，如哈尔式或离子。

Answer 2

让我们把这一点分解一下，因为您可能意外地问了很多问题，这些问题在一个简短的段落中很难回答:)

首先，是什么使REST成为？

REST使用HTTP方法的子集和协议本身来传输API数据并将更改传输到API。换句话说，它是一个客户机-服务器协议，它使用端点的参数、方法、头以及主体和/或查询参数来操作。它必须是无状态的，这意味着我们必须能够在任何时候发送任何电话，简单地说。

我们使用了几种HTTP方法来获取数据、更新数据、创建数据和删除数据。但是，除了这一点之外，没有任何严格的标准来定义这些端点的结构或它们的行为方式。然而，也有一些松散的规则。

比较REST和GraphQL是很常见的，但是，这种比较并不总是有意义的，因为我们只是比较两种方法(其中有很多种)来创建API，而不是将苹果与苹果进行比较。GraphQL是一种规范，它创建了一种新形式的类型化、无状态关系API，它与JSON和Swagger更类似于REST。

但是，GraphQL呢？

HTTP实际上看起来与REST相当，但实际上，它只是针对通过GraphQL端点可访问的GraphQL模式执行的GraphQL查询。然而，它并不局限于HTTP。这就是我们可以开始看到差异的地方。REST也可能是一种方法，但它已经成为构建HTTP的一种常用方法。GraphQL是一种模式语言、查询语言和API系统，严格地说，它不受HTTP的限制。因此，它不能与REST兼容。(但是，请查看“持久化查询”和“自动持久化查询”，看看我们如何仍然可以使用HTTP )

令人惊讶的是，与HTTP上的GraphQL最接近的实际上并不是REST。它是SOAP，也就是1998年以来的简单对象访问协议()。这是因为SOAP还专注于交换结构化信息。

GraphQL非常有利于对关系数据建模，并为我们提供一个可以自由构造以访问关系节点的API。它定义了一种模式语言，它定义了可执行模式的类型和其他约束(可执行模式也分为修改/查询，与REST方法没有不同)，以及我们可以使用的查询语言来遍历这个模式图。

最后，在这里要求一个替代方案是很困难的。很多时间已经进入了GraphQL，虽然我知道一些较小的替代方案，但没有一个比这更受欢迎。在这里需要注意的是，GraphQL只是一种规范，当你把其他东西都拿走的时候。因此，寻找“替代方案”并不重要，因为它有几个实现，并且它构建了一个生态系统。换句话说，它不仅被Facebook采用，而且这种广泛的采用有助于社区工具。