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 表示嵌套对象输入类型的数组