GraphQL 或 REST [关闭]

Posted

技术标签:

【中文标题】GraphQL 或 REST [关闭]【英文标题】:GraphQL or REST [closed] 【发布时间】:2017-04-29 17:20:51 【问题描述】:

有人尝试开发 GraphQL 而不是 RESTful API?有人可以给出现实生活(不仅是理论上的)利弊吗?基本上,根据我的研究,我发现 GraphQL 的强大之处在于获得您真正需要的东西。在使用 REST API 的情况下,您通常必须发出一系列请求,并且您可以轻松获取比您真正需要的更多信息。

花时间研究和学习 GraphQL 是否值得?有没有引起您注意的错误或干扰?

【问题讨论】:

另见***.com/q/40671105/4715679 另见***.com/questions/40689858/… 【参考方案1】:

这个问题主要是基于意见的。

但根据我的经验: RESTful-API 上仅针对一件事的多个请求通常表明 API 设计缺乏,即所需的资源不可用,因此需要从不同的资源中收集东西来弥补这一点。

一个可以被 GraphQL 轻松替换的 REST-API 表明,该 API 实际上是一个 CRUD-HTTP-API,在 REST-Evangelists 中被认为是一种反模式。

另外值得注意的是,GraphQL 将责任放在了客户端,因为支持 API 被简化为只需要查询的数据存储。另一方面,REST 强制执行客户端的行为,因此减少了对它的责任。客户端被简化为类似于浏览器的东西。

在某些情况下,一种或另一种方法会产生更好的结果,但这在很大程度上取决于您的情况。

【讨论】:

当您说Multiple requests on a RESTful-API for just one thing often indicates a lack in the API design, namely the needed resource was not available and therefore stuff needs to be gathered from different resources to compensate for this 时,您是对的。最初每个团队都会制作优化的端点(获取所有合并数据)。但是随着时间的推移,我们需要更多的客户端数据,而这在初始阶段是不需要的,然后我们使用现有的端点并进行多次调用,而不是创建一个新的优化端点。 因此,即使我们避免多次调用,我们也必须在这里做更多的工作。我相信使用 GraphQL 会变得非常简单 关键是,如果您想推动客户行为,您必须倾向于休息,如果您不关心数据的用途,GraphQL 是一个可行的选择。 REST 的坏名声在很大程度上来自“所谓的 REST-API”,因为它们的资源是数据库实体的代表。当然,优化或添加资源(不一定是端点)需要一些工作,但这在技术上很容易做到。 我同意。另一方面,你说The bad reputation of REST comes from 'so called REST-APIs' to a very large degree, because their resources are merley a representation of database-enitites.我的意思是,即使它们只是数据库实体的表示,称它们为rest api有什么问题? 他们缺乏超媒体(文本和控件(例如链接))。

以上是关于GraphQL 或 REST [关闭]的主要内容,如果未能解决你的问题,请参考以下文章

无法使用 graphq-request 表示嵌套对象输入类型的数组

JSON Schema 到 GraphQL 模式转换器 [关闭]

GraphQL 优于 REST?

GraphQL正在超越REST

GraphQL 是不是具有与 REST 相同的缓存能力

转换为数值失败 - GraphQL