GraphQL与REST孰优孰劣？（代码比较篇）

REST并不是第一个进行Web通信的协议，十几年来，它一直统治着API领域。

近期来，由Facebook设计的GraphQL正在变得越来越流行，它的目标是克服REST的某些缺点，但实际上没有一种技术是完美的。

GraphQL与REST相比有什么优点？为什么在项目中使用GraphQL?

REST API已知的问题

首先，我们讨论REST的一些缺点，GraphoQL如何尝试解决它们。主要有如下三个方面：服务器过多的往复，获取过多/不足，缺乏一些灵活性。

1）使用REST API连接服务器的次数过多

比如我们正在开发一个社交媒体的应用程序，有一个需求是显示所有用户的新帖子，包括用户名以及个人资料，照片等。

在REST中，需要向/api/posts发送GET请求，以获取帖子，这将返回一个帖子的标题、内容、标签、日期以及用户ID等的一个Json对象。

接下来，需要请求每个帖子，向/api/user/:id/发送GET请求，以获取相关用户的名字，头像和相关信息。

当为每个用户发出GET请求时，一页的服务器通信就会很多！

而使用GraphQL,只需要走一趟服务器就可以获取所需要的全部：

query {
    posts {
        title,
        content,
        tags,
        date,
        user {
            username,
            avatar,
            catchphrase,
            favorite_dog
        }
    }
}

尽管在比较小的范围内，多次访问服务器也没有什么关系。但是，一旦大量的请求数据，则API调用会大量的增加，减少API请求次数，则性能会因此受益，因此GraphQL则更容易实现。

REST API中的过度获取和不足获取

REST API的相关问题就是获取过多和不足。在REST API中，当命中一个节点时，不论是否需要全部，我们都要获取这些相同的数据。

假如我们只需要其中某人的用户名和头像，比如/usr/:id会返回用户名、头像、个性化和喜欢的动物等字段，不管你需不需要，都能取得这些信息。

想要显示单个用户的帖子，我们需要用户信息和帖子的内容。如果我们想从用户结点获取用户信息，仍然需要点击posts节点，并使用userid检索。

// First we get the user's info
GET /api/users/42

{
    "username": "Mr. T",
    "avatar": "http://example.com/users/42/pic.jpg",
    "catchphrase": "I pity the fool",
    "favorite_dog": "beagle"
}

// Then we get their posts
GET /api/users/42/posts

{
    "posts": [{
        "title": "Hello World",
        "content": "Hi everyone!"
        "tags": "first post"
        "date": "July 1, 2020"
    }]
    // etc.
}

如同前面的例子，GraphQL可以允许用户用一个节点获取想要的内容来解决了问题。

REST API缺少灵活性

在前面的基础上，REST依赖于创建符合前端需求的API。如果你可以预计前端到达指定节点时需要什么，则可以精确地调整检索到的数据，以匹配该前端视图。

当前端视图静态化较多时，这种方法效果会很好。如果前端经常会修改，开发者会希望返回的数据能有更大的灵活性。

同样，如果API被具有不同需求的各种客户端使用，那么REST API的灵活性就会变得差强人意了。

而GraphQL通过允许检索不同的数据配置，能够提供这种灵活性。

// If I just need the username and avatar:

query {
    users {
        username,
        avatar
    }
}

// If I need their favorite dog breed, too.

query {
    users {
        username,
        avatar,
        favorite_dog
    }
}

是用REST还是GraphQL?

从上面看来，GraphQL比REST要更好，但也不全是。

人们在开发应用程序时，每个体系结构都各有利弊，REST和GraphQL也不例外。

以下是一些开发者需要考虑的事情：

1）如果你需要易于使用的内容，请选择GraphQL；
2）正确执行REST需要学习，如果还不是很熟悉，那么用GraphQL可以轻松创建出色的API。
3）如果用GraphQL，要学会如何处理错误
4）REST API很好地利用了HTTP的错误报告功能
5）REST可能更适合微服务
如果在后端使用微服务，则REST可能会更好地实现目标，它可以使关注点分开。
6）GraphQL的统一数据图形非常有用。

结论

与所有其它内容一样，在REST和GraphQL之间进行选择时需要考虑一些细节。在项目选型时取决于你的需求与当下资源。