文章由专业的Laravel开发者社区转发，原文链接：https://learnku.com/laravel/t...这个话题在开发社区讨论了一段时间，众说纷纭在它和Viewpoint上，那么我应该使用哪一个？一个有很多成长空间但经验丰富的老手的充满活力的新人？在此之前，让我们了解REST和GraphQL。什么是休息？REST全称RepresentationalStateTransfer（英文：RepresentationalStateTransfer，简称REST），符合特定的准则，是对WebAPI实现的约束。它是RoyFielding博士在其博士论文中提出的一种软件架构风格。它鼓励客户端和服务器以无状态模式交换信息。请记住，并非所有API都是REST，但所有RESTful服务都是API。什么是GraphQL？GraphQL是一种用于WebAPI的查询语言。它由Facebook于2012年创建，并于2015年开源。它既不是架构模式，也不是Web服务。它是查询从各种数据源接收到的数据的中介。这些数据源可以是数据库或网络服务。多年来，REST已成为WebAPI的事实标准。由于它使用标准的HTTP方法（GET、POST、PUT、DELETE等），它也随着Internet上Web应用程序的增加而发展壮大并流行起来。此外，它的语言和平台独立性使其成为创建Web服务的更好选择。因为每条数据都被认为是调用URL时要发送的资源，所以甚至可以使用Web浏览器或使用cURL请求来调用它。REST的缺点虽然REST很成功，但是由于RESTful服务的规模和复杂性越来越大，它的缺点也变得非常明显1.多终端（多种数据交互）在RESTful服务中，一个URL代表一个资源。因此，当你想要获取多个资源时，你不得不请求多个不同的URL，进而导致多次数据交互。当我们考虑博客应用程序时。一个博客下有多个评论的情况。通常我们要调用的URL如下GET/posts/-获取特定博文GET/posts//comments-获取与上述博文关联的所有评论GET/posts//comments/-获取特定博客下的特定评论您会注意到我们正在请求更多的URL。这是因为实体（这里可以理解为博文和评论）之间的关系比较复杂。随着应用程序变得越来越复杂，管理这些API变得越来越困难。2.Over-fetching/post-fetchingdata有时请求API接口时，会获取到不必要的数据和相关数据，有时又获取不到足够的数据，最后会出现多次往返。这是RESTful服务中的常见问题。在某些情况下，你可能只需要2-3个值，但你可以获得大约20-25个值作为响应。这只会导致通过增加响应时间来传输大量未使用的数据。在后一种情况下，您可能需要从单个URL获取更多信息，因此需要多次往返。这也导致客户端获取所有所需数据的时间成本增加。3.API版本控制API版本控制是一种避免因更改响应格式而破坏客户端应用程序的方法。当API响应格式发生变化时，将创建一个新版本。这样做是为了让生产客户端应用程序可以按预期运行，并为开发人员提供一些休息时间来迁移到新的API版本。但是这种版本控制是一个问题，因为当发布新版本时，它意味着新的URL。API维护和使用变得困难并且经常导致重复代码。4.弱类型并非我们从RESTful服务接收到的所有数据都是强类型的，即它们没有被正确地赋予特定数据。这在记录API时会出现问题，因为我们必须通过调用URL来指定客户端可以期望的数据类型。5.客户被蒙在鼓里。客户端在收到响应之前不知道响应结构。因此，客户被蒙在鼓里。这通常会导致一些错误和数据无法正确处理，从而降低使用API的可靠性。GraphQL的优点GraphQL是由Facebook发明的，主要是为了克服REST的缺点。1.获取所有GraphQL服务的一个请求仅公开一个端点，以便客户端可以传输必要的查询以检索数据。使用我们之前考虑的相同示例，让我们看看GraphQL查询{findPost(id:){idtitlecontentauthorcomments{idcommentcommentedBy}}}如您所见，我们只获取所有必要的数据。因此，当您需要一个新字段时，只需将其添加到查询中，它就会出现在响应中2.强类型GraphQL受强类型模式控制。这些类型既可以是原始类型，也可以是派生类型。强类型系统允许API自我记录，以便客户知道在查询特定查询时会发生什么。3.Client-drivenGraphQL为客户端提供了一种声明性语法来准确指定他们需要哪些字段。这消除了由于客户端基于模式向GraphQL服务器声明其数据需求而导致数据冗余和不足的可能性。4.API演化因为GraphQL中的一切都是由schema驱动的，新的字段不会影响已有的字段，而且GraphQL还为过时的字段提供了@deprecated注解，所以GraphQL的扩展不是问题。这消除了对API版本控制的需要。5.传输层不可知这是GraphQL的一大优势。API服务器可以通过HTTP、HTTPS、WebSockets、TCP、UDP等协议交换信息。这是因为GraphQL很少关心客户端和服务器之间如何交换信息。GraphQL的缺点哇，众所周知，GraphQL很棒。但是这个世界上的一切都有缺陷，GraphQL也不能幸免。1.缓存功能不成熟GraphQL不支持浏览器和手机缓存，这与使用本地HTTP缓存机制的RESTful服务不同，因此我们不得不付出额外的努力来实现GraphQL缓存。虽然有像Relay这样的工具提供一些缓存支持，但它们不如RESTful服务使用的缓存机制成熟。2.验证和错误报告RESTful服务利用HTTP状态代码来处理可能遇到的不同错误。对于开发人员来说，这使得API的验证变得非常简单和无痛。但是使用GraphQL服务总是返回200OK响应。典型的GraphQL错误消息如下所示，状态代码为200OK。{errors:[{message:'Someerroroccurred'}]}这使得处理错误场景变得非常困难，并使验证过程非常繁琐。3.暴露模式和资源攻击与RESTful服务不同，GraphQL服务需要客户端知道要查询的数据模式。如果您将API公开给第三方，基本上就是在公开您的内部数据结构。必须非常小心，因为客户端可以在不花费大量费用的情况下发起连接查询，这可能会导致对服务器的拒绝服务(DoS)攻击。4.安全——身份验证和授权GraphQL社区仍然对如何处理GraphQL服务的安全部分感到困惑。目前还没有集成身份验证和授权的本地解决方案。它通常被抽象到业务逻辑层来授权用户，但我们是否真的必须解析和验证未经身份验证的用户的查询仍然是GraphQL领域的一个问题。5.N+1查询问题在RESTful服务中，很容易记录执行的SQL查询并进一步优化。但在GraphQL的情况下，解析本质是动态的，因此很难得到准确的查询并进一步优化。有时字段解析器会导致N+1查询问题和复杂的连接操作。但是Facebook正在开发像DataLoader这样的工具来解决这个确切的问题。所以，也许在未来，它不会是一个劣势。6.年轻的生态GraphQL在这个API生态系统中非常像一个婴儿，这意味着随时可能出现错误和破坏性更改，因此我们在使用任何与GraphQL相关的库和模块时都必须非常小心。总结首先让我说GraphQL只是一个工具，而REST是一种架构模式。如果说GraphQL正在取代REST，那就大错特错了。但在这个微服务时代，我们将API分离并创建到原子级别，我们可以利用两者，因为没有灵丹妙药。GraphQL服务将性能作为重中之重，而RESTful服务则保持可靠性。GraphQL节点可以通过现有的RESTful服务暴露为节点，例如/graphql，它可以充当运行GraphQL查询的网关，同时也为某些场景维护REST节点。在某些情况下GraphQL更好，而在其他情况下REST必然更好。所以，在说哪个更好之前，需要分析一下涉及到的需求和数据，才能知道哪个更合适。
