问题描述
是否有人尝试开发 GraphQL 而不是 RESTful API?有人可以给出现实生活(不仅是理论上)的利弊.基本上，从我的研究中，我发现 GraphQL 的力量是准确地获得您所需要的东西.在使用 REST API 的情况下，您通常需要发出一系列请求，并且可以轻松获取比您真正需要的更多信息.
Did someone try developing a GraphQL instead of RESTful API? Can someone give real life (not only theoretical) pros and cons. Basically from my research I found that the GraphQL power is to get exactly what you need nothing more. Where with REST APIs, you often have to make a series of requests and you can easily get back more information than you really needed.
花时间研究和学习 GraphQL 是否值得?有没有引起您注意的错误或阻碍?
Is it worth the time spent on researching and learning GraphQL? Any bugs or showstoppers that get your attention?
推荐答案
这个问题主要是基于意见的.
This question is primarily opinion-based.
但根据我的经验:在 RESTful-API 上针对一件事的多个请求通常表明 API 设计存在缺陷，即所需的资源不可用，因此需要从不同的资源中收集内容来弥补这一点.
But from my experience: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 替换的 REST-API 表明，该 API 实际上是一个 CRUD-HTTP-API，这在 REST-Evangelists 中被认为是一种反模式.
A REST-API that could be easily replaced by GraphQL indicates, that the API was in fact a CRUD-HTTP-API, what is considered an Anti-Pattern among REST-Evangelists.
另外值得注意的是，GraphQL 将责任推给了客户端，因为后备 API 被简化为只需要查询的数据存储.另一方面，REST 强制执行客户端的行为，因此减少了对其的责任.客户端被简化为类似于浏览器的东西.
Also worth noting is, that GraphQL puts responsibilty on the client, because the backing API is reduced to be a datastore that just needs to be queried. REST on the other hand enforces the behaviour of the client and therefore reduces responsibility on it. The client gets reduced to be something similar to a browser.
在某些情况下，一种或另一种方法会产生更好的结果，但这在很大程度上取决于您的情况.
There are cases the one or the other approach would yield better results, but that greatly depends on your situation.
这篇关于GraphQL 或 REST的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！