【发布时间】：2017-04-29 17:20:51
【问题描述】：
有人尝试开发 GraphQL 而不是 RESTful API？有人可以给出现实生活（不仅是理论上的）利弊吗？基本上，根据我的研究，我发现 GraphQL 的强大之处在于获得您真正需要的东西。在使用 REST API 的情况下，您通常必须发出一系列请求，并且您可以轻松获取比您真正需要的更多信息。
花时间研究和学习 GraphQL 是否值得？有没有引起您注意的错误或干扰？
【问题讨论】：
【发布时间】：2017-04-29 17:20:51
【问题描述】：
这个问题主要是基于意见的。
但根据我的经验： 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有什么问题？ -
他们缺乏超媒体（文本和控件（例如链接））。