假设客户是一位名叫安娜的人，她坐在家里，想从餐馆订购玛格丽特披萨，从超市订购洗衣粉。 Anna 聘请 REST 为她获取这些产品。不幸的是，休息只能单向进行，这就是安娜首先要披萨的原因。然后，REST 会提供餐厅菜单上的所有内容。安娜拿走了她想要的披萨，然后把剩下的扔掉了。 REST 拿到食物后，前往超市购买安娜想要的清洁剂。他再次带来了整个系列。安娜选择了她想要的洗涤剂，并扔掉了所有其他产品。 Anna的经历清楚地表明了REST的以下缺点：
需要多个端点
由于 REST 仅返回固定的数据结构，因此必须创建多个端点以便能够从服务器获取各种数据。例如，Anna 无法同时说出她的愿望，因为 REST 必须从多个端点一个接一个地获取这些愿望，并且并行查询是不可能的。端点看起来像这样：
URL/api/restaurant
URL/api/supermarkt
过度获取
REST 通过请求向客户端返回大量数据，因此客户端必须搜索并选择 比利时消费者电子邮件列表 自己真正需要的数据。这会导致由于不需要的数据而产生冗余，从而影响带宽并消耗存储空间和时间。
欠取
REST 一次只能查询一个端点，但信息可以分布在多个端点上。因此，有时客户端需要连续执行多个查询才能获取所有信息。所以REST必须走两条路才能满足Anna的要求。对于单个请求，例如到达终点/api/restaurant，安娜只会收到披萨。
然而，这两个问题都可以通过适当的 API 设计来解决。 REST API 背后有一种非常强大的语言，客户端可以使用它来有效地表达自己。大多数 Web 应用程序开发人员都熟悉这种语言。
客户端可以发送由服务器解释的字符。例如，超市的产品在数据库中用 EAN 代码进行标识。为此，客户端将所需产品的 EAN 代码传递给 REST API。 REST API 将代码传递到服务器，然后服务器在数据库中搜索所需的产品。如果服务器可以满足客户端的请求，REST API 就会获取数据并将其返回给客户端。否则，服务器会向 REST API 返回相应的错误消息，例如，如果产品不再可用。为端点找到最有效的名称可以产生很大的影响，并带来更好的 API 设计。
这意味着 Anna 应该准确描述 REST 应该向服务器请求什么。例如，合适的端点如下所示
通过这个查询，安娜只会得到她想要的产品和披萨。这种设计避免了订购过多和订购不足。但如果安娜想要更多产品怎么办？然后必须进行进一步的 API 调用，就像超市一样。由于餐厅的API不依赖于EAN码等标准，因此我们需要考虑如何识别其他资源。但是，如果 Anna 有来自不同资源的完整产品列表怎么办？然后我们还需要多个 REST 端点。这意味着从后端请求的资源越多，需要的端点就越多。这里我们再次遇到需要多个端点的问题。
该解决方案附带 GraphQL
Facebook 面对 2012 年提到的挑战，开发了一个名为 GraphQL 的规范。目前，围绕该规范已经形成了许多实现和完整的生态系统，支持其在当前项目中类似于 REST 的使用。 GraphQL 在以下方面与 REST API 不同。这些定制使 API 设计能够应对 REST 的挑战。
单一端点
GraphQL 只有一个端点。因此，PUT、DELETE 等方法不需要端点。请求通过查询来描述，因此只需向端点发送一个请求。这个查询是用一种特殊的查询语言来描述的，类似于SQL。然后由服务器解释。一个示例是查询 URL/graphql?query=annaswuensche。在“annaswuensche”中，客户可以描述所需的所有数据。